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PREFACE  TO  THE  ISD  MANUAL  OF  STANDARDS 
Mission  Statement 

To  establish,  approve,  implement,  and/or  maintain  policies, 
standards,  procedures,  and  guidelines  which  provide  for  a  uniform, 
controlled,  efficient,  reliable  and  secure  operating  environment 
for  Statewide  information  processing  services  supported  by  the 
Information  Services  Division. 

Assumptions 

1.  The  intent  of  the  Standards  Project  is  to  provide  information 
that  will  be  utilized  by  the  Information  Services  Division  to 
operate  according  to  its  Mission  Statement. 

2.  The  scope  of  the  Standards  Project  will  be  the  Information 
Services  Division's  policies,  standards,  procedures,  and 
guidelines  known  as  the  ISD  MANUAL  OF  STANDARDS.  (Policies, 
standards,  procedures,  and  guidelines  will  be  collectively 
referred  to  as  Standards.) 


Objectives 

1.  To  establish,  develop  and  maintain  Information  Services 
Division  policies  in  a  manner  consistent  with  the  Department 
of  Administration's  direction. 

2.  To  establish,  approve,  implement  and  maintain  Information 
Services  Division  Standards. 

3 .  To  review  and  approve  Bureau  Standards  to  assure  adherence  to 
Information  Services  Division  policies. 

4.  To  provide  an  environment  which  allows  management  to  reasonab- 
ly assure  users  that  information  processing  services  will  be 
carried  out  in  a  standardized,  effective,  reliable  and  secure 
manner. 

5.  To  promote  flexibility  through  the  development,  establishment 
and  maintenance  of  Standards  which  will  allow  reasonable 
discretionary  powers  to  individual  operating  units  within  the 
Division  and  within  State  government. 

6.  To  establish,  approve,  implement  and  maintain  Standards  which 
allow  adherence  to  accepted  and  approved  security  practices 
and  statutory  requirements. 


GUIDELINES  FOR  STANDARDS  DOCUMENTATION 

1.  Distinguish  between  policies,  standards,  procedures,  and 
guidelines  in  technical  descriptions. 

2.  State  all  policies  first. 

3.  Make  it  simple. 

4.  Plan  out  a  lengthy  draft  arranging  material  into  a 
hierarchy  of  topics.  Give  each  topic  a  meaningful 
heading. 

5.  Use  as  few  words  as  possible  to  maintain  clarity  and 
readability  in  the  text. 

6.  Plan  ahead  and  develop  Standards  that  will  be  needed  at 
some  point  in  the  future. 


DEFINITIONS 


POLICY  A  statement  of  management  philosophy  on  a  general 

principle  or  the  attainment  of  a  long-term,  agency- 
wide  objective. 

STANDARD  A  detailed  statement  to  support  operating  policy. 

This  statement  defines  responsibilities  and  relates 
to  specific  conditions  and  practices.  A  standard 
identifies  what  must  be  done  to  implement  policy. 

PROCEDURE  Detailed  statements  to  implement  standards.   These 

statements  identify  the  sequence  of  events  that  will 
be  followed.  Procedures  identify  how  things  will 
be  done. 


GUIDELINE  Detailed  statements  to  support  standards  and/or  pro- 
cedures. These  statements  identify  the  recommended 
sequence  of  events  that  may  be  followed. 

BULLETIN  A  document  containing  urgent  Standards  information 

that  warrants  publishing  and  distribution  outside 
of  the  normal  Standards  development  and  publication 
process. 

EXCEPTION  Written  approval  for  a  task  to  be  done  in  a  manner 

that  deviates  from  a  standard  or  procedure. 

VIOLATION  An  unauthorized  break  from  a  standard  or  procedure. 

ENFORCEMENT  —  A  defined  means  of  ensuring  conformance  with 
standards  and  procedures,  and  a  way  of  maintaining 
control  over  exceptions. 


AUDIENCE 


APPENDIX 


Defined  groups  of  recipients  of  Standards  document- 
ation. Each  group  will  have  similar  informational 
needs  based  on  their  functional  responsibilities. 

A  collection  of  supplemental  data  or  information 
that  supports  a  set  of  Standards.  Appendices  may 
be  used  to  provide  one  source  for  topics  that  are 
referenced  more  than  once  or  to  isolate  a  list  of 
items  that  require  periodic  changes. 


RULES  AND  PROCEDURES 

In  order  to  implement  meaningful  Standards   in  a  timely  and 
efficient  manner,  the  following  methods  will  be  used: 

Policies: 

1.  Policies  will  be  established  or  revised  by  the  Informa- 
tion Services  Division  management. 

2.  All  policies  will  require  the  Division  Administrator's 
approval . 

Standards; 

1.  Standards  will  be  established  or  revised  by  Information 
Services  Division  management. 

2.  All  standards  will  require  the  Bureau  Chief's  approval. 

3.  Standards  that  cross  Bureau  lines  must  be  approved  by  the 
respective  Bureau  Chiefs. 

4.  Proposed  standards  must  support  an  approved  policy. 
Procedures; 

1.  Procedures  will  be  established  or  revised  by  Information 
Services  Division  management  or  their  designated 
representatives . 

2.  All  procedures  will  require  the  Bureau  Chief's  approval. 

3.  Procedures  that  cross  Bureau  lines  must  be  approved  by 
the  respective  Bureau  Chiefs. 

4.  Proposed  procedures  must  support  an  approved  standard. 
Guidelines: 

1.  Guidelines  may  be  proposed  by  Information  Services 
Division  personnel. 

2.  All  guidelines  (new  or  revised)  will  require  the 
respective  Bureau  Chief's  approval. 

3.  Guidelines  that  cross  Bureau  lines  must  be  approved  by 
the  respective  Bureau  Chiefs. 

4.  All  guidelines  must  support  approved  standards  and/or 
procedures. 


SUBMISSION  OF  POLICIES,  STANDARDS,  PROCEDURES  AND  GUIDELINES 

1.  Proposed  or  revised  policies,  standards,  procedures  and 
guidelines  may  be  submitted  via  electronic  mail  in  draft 
form  using  WordPerfect  format  to  the  Standards  Coor- 
dinator. 

2.  Proposed  policies,  standards,  procedures  and  guidelines 
will  be  formatted  according  to  the  approved  format  for 
each,  reviewed  and  returned  to  the  originator  for 
approval . 

3.  Revised  policies,  standards,  procedures  and  guidelines 
will  be  reviewed  and  updated  according  to  the  origin- 
ator's intent,  and  returned  to  the  originator  for 
approval. 

APPROVAL  OF  POLICIES.  STANDARDS,  PROCEDURES  AND  GUIDELINES 

1.  Policies,  standards,  procedures  and  guidelines  shall  be 
submitted  to  the  Information  Services  Division  management 
for  final  review  and  approval  prior  to  implementation. 

2.  Policies,  standards,  procedures  and  guidelines  shall  be 
published  quarterly. 

DISTRIBUTION   OF   APPROVED   POLICIES.   STANDARDS.   PROCEDURES   AND 
GUIDELINES 

1.  An  appropriate  number  of  copies  of  each  new  or  revised 
policy,  standard,  procedure  or  guideline  will  be  provided 
to  each  Bureau  and  upper  administrative  level  in  the 
Information  Services  Division  after  it  has  gone  through 
the  approval  phase  of  the  project. 

2.  Each  Bureau  will  be  responsible  for  distributing  new  or 
revised  policies,  standards,  procedures  and  guidelines 
as  required  within  the  Bureau. 

3.  The  Resource  Management  Unit  shall  maintain  a  complete 
set  of  all  policies,  standards,  procedures  and  guidelines 
for  the  Information  Services  Division. 

4.  The  Resource  Management  Unit  shall  be  responsible  for 
copying  and  distributing  new  or  revised  policies, 
standards,  procedures  and  guidelines  as  required  to  other 
State  agencies. 


TYPOGRAPHICAL  LAYOUTS 

The  typographical  layouts  for  policies,  standards,  procedures  and 
guidelines  are  shown  in  the  examples  of  each  on  the  following 
pages.   The  heading  for  all  Standards  will  be: 

POLICY:  Section 

STANDARD:  #: 

PROCEDURE:  #: 

GUIDELINE:  #:  . 

PUB.  DATE: 
REVIEW  DATE: 

PAGE :       OF 


Policies 

The  general  heading  format  for  ISD's  MANUAL  OF  STANDARDS'  Policies 
is  shown  below.   The  heading  information  will  contain: 

POLICY:   Policy  Title  Section  Section  No. 
STANDARD:  #: 

PROCEDURE:  #: 

GUIDELINE:  #: 

PUB.  DATE:    MM/DD/YY 

REVIEW  DATE:    MM/DD/YY 
PAGE:    n  OF  m 


Standards 

The  general  heading  format  for  ISD's  MANUAL  OF  STANDARDS'  Standards 
is  shown  below.   The  heading  information  will  contain: 

POLICY:   Policy  Title  Section  Section  No. 

STANDARD:   Standard  Title  #:  Seg.  No. 

PROCEDURE:  #: 

GUIDELINE:  #: 

PUB.  DATE:  MM/DD/YY 

REVIEW  DATE:  MM/DD/YY 

PAGE:  n  OF  m 


Each  Standard  will  identify  what  must  be  done  to  support  the  Policy 
or  an  aspect  of  it. 


TYPOGRAPHICAL  LAYOUTS  (continued) 


Procedures 


The  general  heading  format  for  ISD's  MANUAL  OF  STANDARDS •  Proced- 
ures is  shown  below.   The  heading  information  will  contain: 


POLICY: 

STANDARD: 

PROCEDURE : 

GUIDELINE: 


Policy  Title 
Standard  Title 
Procedure  Title 


Section  Section  No. 


#: 

#: 

#: 

PUB.  DATE: 

REVIEW  DATE: 

PAGE: 


Seg.  No. 
Seg.  No. 

MM/DD/YY 
MM/DD/YY 
n  OF  m 


Each  Procedure  will  identify  what  must  be  done  to  support  the 
associated  Standard  or  an  aspect  of  it. 


Guidelines 


The  general  heading  format  for  ISD's  MANUAL  OF  STANDARDS'  Guide- 
lines is  shown  below.   The  heading  information  will  contain: 


POLICY: 

STANDARD: 

PROCEDURE : 

GUIDELINE: 


Policy  Title 
Standard  Title 
Procedure  Title 
Guideline  Title 


Section  Section  No. 


#: 

Seg.  No. 

#: 

Seg.  No. 

*: 

Seg.  No. 

PUB .  DATE : 

MM/DD/YY 

REVIEW  DATE: 

MM/DD/YY 

PAGE: 

n  OF  m 

Each  Guideline  will  identify  a  recommended  seguence  of  events  to 
support  the  associated  Standard  and/or  Procedure.  A  Guideline 
may  support  a  Standard  when  no  formal  Procedures  have  been 
identified. 


ISD  STANDARDS  CATEGORIES 


09/21/89 


POLICY 
TITLE  SECTION 

GENERAL  1-12000 

TELECOMMUNICATIONS  1-12100 

HARDWARE  1-12200 

SOFTWARE  1-12300 

INFORMATION  SYSTEMS  1-12400 

RECORDS  MANAGEMENT  1-12500 

SECURITY  AND  CONTINGENCY  PLANNING  1-12  600 


STANDARD 

PROCEDURE 

GUIDELINE 
APPENDIX 


I 
I 
I    I 
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02 
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Public  Documents 


1-12103 
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1-12300 


Management  of  Software  1-12301 

Procurement  of  System  Software  01 

ISD  Supported  Software  02 

Job  Control  Language  03 

JCL  Guidelines  03 

Standardized  Use  of  Software  04 

COBOL  Coding  Guidelines  04 

ADS  Guidelines  04 

PANVALET  (Source  Code  Maintenance)  04 
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03 
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I .  Policy 

The  Department  of  Administration  will  provide  and  supervise  all 
State  government  telecommunications  systems  for  shared  voice  and 
data  services  and  networks  for  agencies,  departments,  colleges 
and  universities. 

II .  Scope  of  State  Government  Telecommunications  Systems 

The  State's  telecommunication  systems  include  any  State  owned, 
leased,  contracted  for,  operated  or  maintained  telecommunica- 
tions equipment,  services  or  facilities  including: 

A.  private  branch  exchanges; 

B.  key  telephone  systems; 

C.  teleconferencing  systems; 

D.  local  and  long  distance  telecommunication  circuits; 

E.  data  communications  equipment; 

F.  video  capabilities; 

G.  land  mobile  radio  equipment; 
H.  telephone  credit  cards; 

I.    facsimile  equipment. 

J.    Local  Area  Networks  (LAN's) 

III .  Authorization 

The  Department  of  Administration  has  been  directed  by  the 
Legislature  to  be  responsible  for  the  provision  and  supervision 
of  communications  systems  (Section  2-17-302,  MCA;. 
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STANDARD: 
PROCEDURE: 
GUIDELINE: 
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IV.   Background 

An  effective  internal  communications  capability  is  a  critical 
requirement  and  strategic  tool  for  government.  An  even  more 
important  requirement  is  ensuring  that  the  government  is 
accessible  to  the  people.  Montana's  sparse  population  spread 
over  great  distances  make  these  goals  more  important,  and  more 
difficult,  to  achieve. 

With  the  divestiture  of  the  AT&T/Bell  system  and  the  increased 
deregulation  of  telecommunications  services,  especially  as 
implemented  in  the  Montana  Telecommunications  Act  (69-3-801, 
MCA)  ,  the  state  has  growing  responsibility  for  planning  and 
managing  its  own  telecommunications  function. 
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I.  Management  of  State  Government  Telecommunications  Systems 

The  Department  of  Administration,  acting  through  the  Telecom- 
munications Bureau  of  the  Information  Services  Division,  is 
responsible  for  the  management  of  the  telecommunications 
services  for  state  government. 

II .  Management  Objectives  for  State  Telecommunications  Systems 

The  Telecommunications  Bureau's  objectives  in  managing  the 
State's  telecommunications  systems  are  to: 

A.  improve  the  availability  and  reliability  of  the  State's 
telecommunications  services; 

B.  deliver  the  best  services  at  the  lowest  possible  cost; 

C.  plan  for  and  provide  system  flexibility  to  meet  changing 
needs  and  opportunities. 

III.  Telecommunications  Bureau  Responsibilities 

The  Telecommunications  Bureau  will  be  responsible  for: 

A.  providing  communications  services  to  all  agencies  of  State 
government ; 

B.  exercising  general  supervision  over  all  existing 
communications  systems  for  all  agencies  of  State  govern- 
ment ; 

C.  planning,  reviewing  and  approving  any  additional  installa- 
tions of  communications  equipment  or  systems  for  all 
agencies  of  State  government,  in  coordination  with  the 
executive  heads  of  the  agencies; 

D.  approving  standards  and  procedures  for  selection,  acquisi- 
tion and  operation  of  communications  equipment; 
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III.  Telecommunications  Bureau  Responsibilities  (continued) 

E.  ensuring  that  all  communications  eguipment  is  properly 
installed  and  maintained; 

F.  providing  assistance  to  the  Legislature,  Governor,  and 
State  agencies  relative  to  state  and  interstate  com- 
munications matters; 

G.  providing  a  means  whereby  political  subdivisions  of  the 
State  may  utilize  the  State  communications  system; 

H.  accepting  federal  funds  granted  by  congress  or  executive 
order  for  any  of  these  purposes,  as  well  as  gifts  and 
donations  from  individuals  and  private  organizations  or 
foundations; 

I.  fostering  the  development  of  new  and  innovative  communica- 
tions systems  and  techniques  within  the  state. 

J.    assisting  departments  and  agencies  in: 

1.  assessing  current  telecommunications  configurations 
needs ; 

2.  planning  for  future  needs; 

3.  training  staff  in  the  use  of  telecommunications 
systems  already  in  place. 

K.  periodically  arranging  meetings  for  Communications 
Coordinators  to  provide  updated  information  on  procedures 
and  available  capabilities,  and  to  exchange  information  on 
common  concerns. 
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IV.  Optional  Responsibilities  for  the  Telecommunications  Bureau 

The  Department  may  provide  assistance  to  political  subdivisions 
or  non-profit  organizations,  upon  such  terms  that  the  Department 
may  establish,  relative  to  State  and  interstate  communications 
systems  and  techniques. 

V.  State  Agency  Responsibilities 

A.  The  responsibility  for  the  approval  of  proposed  changes, 
additions  or  deletions  of  telecommunications  equipment  or 
services  within  a  department  or  agency  shall  reside  with 
that  department  or  agency. 

B.  Each  department  or  agency  shall  assign  one  or  more  in- 
dividuals as  "Communications  Coordinator (s) " . 

1.  The  person(s)  designated  must  have  authority  to 
approve  telecommunications  expenditures  for  the  agency 
or  department. 

2.  The  name(s)  of  the  Communications  Coordinator (s)  shall 
be  provided  to  the  Telecommunications  Bureau. 

3.  If  a  department  or  agency  fails  to  assign  a  Communica- 
tions Coordinator,  the  Telecommunications  Bureau  will 
refer  these  duties  to  the  department's  or  agency's 
chief  administrator,  fiscal  officer  or  highest  ranking 
officer. 

C.  Each  department  or  agency  is  individually  responsible  for 
all  costs  incurred  in  the  operation  of  the  telecommunica- 
tions systems  utilized  by  the  agency. 
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I .    Maintaining  the  State  Telephone  Directory 

A.  The  Telecommunications  Bureau  will: 

1.  maintain  the  online  telephone  directory  of  State 
personnel ; 

2.  annually  issue  a  printed  Montana  State  Telephone 
Directory. 

B.  Communications  Coordinators  are  responsible  for  notifying 
the  Telecommunications  Bureau  of  all  additions,  correc- 
tions, modifications,  or  deletions  of  listings  for  the 
directory  for  their  respective  department  or  agency. 
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Accounting  and  Billing 

A.  Each  month  the  Telecommunications  Bureau  will  bill  agencies 
for  their  equipment,  long  distance  usage,  and  other 
telephone  related  costs. 

B.  The  Bureau  will  provide  detailed  statements  of  the  calls 
made  from  each  extension  or  at  the  most  practical  level  of 
detail  during  the  prior  month. 

C.  Any  billing  questions  should  be  directed  to  the  Account- 
ing Section  of  the  Bureau. 
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I .  Purchase  or  Lease  of  Telecommunications  Equipment 

A.  All  telecommunications  systems  for  State  departments  and 
agencies,  including  private  branch  exchanges  (PBXs)  and 
key  telephone  systems,  are  to  be  obtained  through  the 
Telecommunications  Bureau. 

B.  The  Telecommunications  Bureau  will  coordinate  the  procure- 
ment process  with  the  requesting  agency  and  the  Purchasing 
Division. 

C.  The  Telecommunications  Bureau  requests  that: 

1.  Departments   and   agencies   channel   these   requests 
through  their  Communications  Coordinators. 

2.  Agencies  allow  90  days  lead  time  in  submitting  these 
requests  to  the  Telecommunications  Bureau. 

II .  Telecommunications  Equipment  Available  on  Term  Contract 

A.  The  Telecommunications  Bureau,  in  coordination  with  the 
Purchasing  Division,  maintains  a  term  contract  for  the 
acquisition  of  two-way  radio  equipment. 

B.  All  two-way  radio  equipment  should  be  purchased  through 
the  term  contract. 
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Ordering  Telephone  Equipment  and  Services 

A.  All  requests  for  installation,  modification,  relocation  or 
removal  of  telephone  equipment  and  services  shall  be 
submitted  on  a  Telephone  Service  Request  Form,  available 
from  Central  Stores. 


B.  These  requests  should  be  submitted  to  the  Telecommunica- 
tions Bureau  a  minimum  of  thirty  (30)  working  days  prior 
to  the  requested  service  date. 
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I.  Use  of  State  Telecommunications  Facilities  by  other  Political 
Subdivisions 

A.  The  Department  of  Administration  is  authorized  to  provide 
a  means  whereby  political  subdivisions  of  the  state  may 
utilize  the  State  telecommunications  system. 

B.  Political  subdivision  means  any  county,  city,  municipal 
corporation,  school  district,  special  improvement  district 
or  taxing  jurisdiction,  or  any  other  political  subdivision 
or  public  corporation. 

C.  Requests  from  political  subdivisions  shall  be  submitted  in 
writing  to  the  Telecommunications  Bureau.  The  Bureau  will 
review  these  requests,  particularly  with  respect  to  the 
potential  impact  on  State  agency  use  of  the  systems,  and 
will  respond  to  the  political  subdivision  within  180  days 
of  receipt  of  their  written  request. 

D.  These  other  political  subdivisions  will  be  billed  for  the 
use  of  the  State's  telecommunications  system  at  a  rate 
determined  by  the  Telecommunications  Bureau. 

II.  Non-profit  Organization  Use  of  the  State  Telecommunication 
Systems  Allowed 

A.  The  State  telecommunication  systems  are  available  for  use 
by  in-state  non-profit  organizations  that  meet  one  of  the 
following  three  criteria: 

1.  there  is  a  close  connection  between  the  organization 
and  the  State; 

2.  the  State  is  significantly  involved  in  the  activities 
of  the  organization; 

3.  the  organization  performs  a  public  function  tradition- 
ally performed  by  the  State. 
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II.   Non-profit  Organization  Use  of  the  State  Telecommunication 
Systems  Allowed  (continued) 

B.    Non-profit  organizations  must  make  written  requests  to  the 
Department  of  Administration  for  access  to  its  systems. 

1.  These  written  requests  must  provide  adequate  detailed 
information  for  the  Department  to  determine  if  the 
non-profit  organization  meets  any  of  the  criteria 
defined  above. 


2.  Use  of  the  State's  telecommunication  systems  shall  be 
authorized  for  organizations  meeting  the  criteria 
based  upon  the  technical  requirements  of  the  non- 
profit organization's  needs  as  indicated  by  the 
request  and  the  potential  impact  on  State  agency  use 
of  the  systems. 

3.  In  consultation  with  the  appropriate  agency,  the 
Department  will  approve  or  disapprove  requests  for 
access  by  non-profit  organizations  within  180  days  of 
receipt  of  written  requests. 

C.  Non-profit  organizations  will  be  billed  for  use  of  the 
State's  telecommunication  systems  under  procedures  and  at 
rates  developed  by  the  Department. 
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I .  Management  of  Local  Area  Networks 

Local  Area  Networks  (LAN's)  are  managed  as  an  integral  part  of 
the  State's  Telecommunications  Network. 

II.  Local  Area  Network  Topology 

A  standard  LAN  topology  will  be  used  to  provide  a  manageable 
interface  for  all  Local  Area  Networks. 


A. 


The  Token  Ring,  IBM  802.5,  will  be  the  standard  topology 
used  for  all  Local  Area  Networks. 


Token  Ring  components  compatible  with  IBM  components  and 
environment  will  be  considered  standard  and  supported  by 
ISD.  Appropriate  components  will  be  listed  on  current  term 
contracts. 


III.  Technical  Support  for  Local  Area  Networks 

To  insure  connectivity  of  the  State's  diverse  computer  systems 
the  Information  Services  Division  will  maintain  a  local  area 
network  support  staff  which  can  respond  to  agency  needs  for 
technical  support  of  the  standard  Local  Area  Network  topology. 
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Policy 

State  telephones  are  provided  for  the  conduct  of  State  business. 
In  addition  to  State  business,  the  State's  telecommunication 
systems  may  be  used  by  State  employees  and  officials  for  local 
and  long  distance  calls  to  latch-key  children,  teachers, 
doctors,  day-care  centers  and  baby  sitters,  to  family  members 
to  inform  them  of  unexpected  schedule  changes,  and  for  other 
essential  personal  business. 

A.  The  use  of  the  State's  telecommunication  systems  for 
essential  personal  business  must  be  kept  to  a  minimum,  and 
not  interfere  with  the  conduct  of  State  business. 


B.  Essential  personal  long  distance  calls  must  be  either 
collect,  charged  to  a  third  party  non-state  number,  or 
charged  to  a  personal  credit  card. 


POLICY:   Use  of  the  State  Telephone  System  Section  1-12102 


STANDARD: 
PROCEDURE: 
GUIDELINE: 


State  Issued  Telephone  Credit  Cards 


t  Cards    # 

01 

# 

# 

PUB.  DATE 

09/21/89 

REVIEW  DATE 

PAGE 

1  OF  1 

Use  of  State  Issued  Telephone  Credit  Cards 


A.  State  issued  telephone  credit  cards  are  provided  for  the 
conduct  of  state  business  while  in  a  travel  status,  and 
are  not  to  be  used  for  personal  calls. 

B.  Personal  long  distance  calls  while  in  a  travel  status  are 
to  be  made  either  collect,  charged  to  a  third  party  non- 
state  number,  or  charged  to  a  personal  credit  card. 
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I .  Development  of  Agency  Policies 

Agencies  are  encouraged  to  develop  and  promulgate  telecom- 
munications policies  appropriate  to  their  own  needs. 

II.  Instruction  on  the  Use  of  State  Telephones 

Each  State  agency  is  responsible  for  instructing  their  person- 
nel on  the  policies,  use  and  controls  relating  to  State 
telephones . 

III.  Enforcement 


Each  State  agency  is  responsible  for  the  appropriate  enforce- 
ment of  policy  1-12102  Use  of  the  State  Telephone  System  and 
related  agency  policies. 
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Policy 

All  records  of  use  of  the  telecommunication  systems  created, 
maintained  and  managed  by  the  Department  are  public  documents 
and  subject  to  review  by  the  public,  unless  protected  by 
statute. 
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Policy 

The  Information  Services  Division  will  provide  and  maintain 
software  products  for  the  development  and  maintenance  of  State 
agency  application  systems  on  mainframe  and  microcomputers. 
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I .  Procurement  of  Mainframe  Software 

A.  All  mainframe  software  will  be  evaluated  and  acquired 
according  to  internal  procedures  established  by  the 
Information  Services  Division. 

B.  Agencies  perceiving  a  need  for  mainframe  software  that 
is  not  currently  available  should  contact  the  ISD  Admin- 
istrator. 

II .  Procurement  of  Microcomputer  Software 

A.  All  microcomputer  software  will  be  evaluated  for 
consideration  as  a  state  standard  according  to  internal 
procedures  established  by  the  Information  Services 
Division. 


B.  Agencies  perceiving  a  need  for  a  new  or  different  state 
standard  in  microcomputer  software  should  contact  the  ISD 
Administrator. 


POLICY: 

STANDARD: 

PROCEDURE : 

GUIDELINE: 


Management  of  Software 
ISD  Supported  Software 


Section  1-12301 


# 

02 

# 

# 

PUB.  DATE 

09/21/89 

REVIEW  DATE 

PAGE 

1  OF  1 

Supported  Software 

A.  New  software  products  acquired  through  the  software 
procurement  procedures  will  be  reviewed  to  determine  the 
appropriate  level  of  support. 

B.  Each  software  product  supported  by  ISD  will  be  assigned 
a  support  level  that  identifies  the  scope  of  support  that 
will  be  provided  for  the  product.  The  support  levels 
are: 


1.    FULL  SUPPORT 

Maintain  a  Vendor  Supported  Release 

Monitor  and  Maintain  Performance 

Provide  User  Education 

Document  Standards,  Procedures,  and  Guidelines 

Maintain  Technical  Expertise 

Assure  System  Compatibility 

Assist  in  Problem  Resolution 


LIMITED  SUPPORT 

Maintain  a  Vendor  Supported  Release  if  possible 

Provide  Limited  or  No  User  Education 

Assure  System  Compatibility  within  Time  and 

Resource  Constraints 

Assist  in  Problem  Resolution  within  Time  and 

Resource  Constraints 

Periodic  Review  for  Software  Disposal 

SUNSET  SUPPORT 

Plan  for  Software  Disposal 


4 .    SPECIAL  CASE 

These  products  are  available  through  special  agree- 
ments with  selected  agencies.  The  type  and  extent 
of  the  support  provided  by  ISD  depends  on  the 
particular  product  and  the  special  arrangements  made 
with  the  user  agency.  These  products  are  not 
available  fox  general  use. 

Appendix   B   lists   the   supported  mainframe   software 
products. 

Appendix  C  lists  the  supported  microcomputer  software 
products. 
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Job  Control  Language  Requirements 

Job  Control  Language  (JCL)  for  jobs  running  on  the  ISD  mainframe 
computer (s)  must  meet  the  following  requirements. 

A.    JOB  Card 

//XYSSSSSS  JOB  (AAAAA/CC(,FLD-l,FLD-2, . . . ,FLD-8) ) , 
//  MMMM.BB.NNN. . .N( , Keyword  Parameters) 

1.  XYSSSSSS  -  Job  Name 

a.  The  Job  Name  field  will  be  edited  for  validity. 
Jobs  with  invalid  Job  Names  will  be  cancelled. 

b.  X  identifies  the  system  component  that  was  used 
to  submit  the  job,  i.e.  local  reader,  TSO,  RJE, 
CICS,  etc.  System  Component  Codes  are  identified 
in  Appendix  B. 

c.  Y  identifies  the  agency  or  group  submitting  the 
job.  Agency  and  group  identifiers  are  assigned 
by  the  Information  Services  Division  and  listed 
in  Appendix  C. 

d.  SSSSSS  are  six  alphanumeric  characters  of  the 
user's  choice  to  identify  the  job. 

2.  (AAAAA,CC(FLD-l,FLD-2,...,FLD-8) )  -  Job  Accounting 

a.  AAAAA  is  the  five  digit  account  number  used  for 
billing.   This  is  a  required  field. 

b.  CC  is  the  Operation  Code  (OP-CODE)  that  iden- 
tifies the  type  of  job  being  run.  This  is  a 
required  field.  Operation  Codes  are  listed  in 
Appendix  D. 

c.  (,FLD-l,FLD-2, . . . ,FLD-8)  identifies  the  eight 
optional  extended  accounting  fields. 

(1.)  Agencies  can  define  these  fields  to  meet 

their  own  needs. 
(2.)  Fields  that  are  used  may  have  from  one  to 

seven  numeric  digits  and  will  be  edited  to 

ensure  that  they  are  numeric  and  do  not 

exceed  seven  digits. 
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(AAAAA, CC (FLD-l,FLD-2, ... ,FLD-8) )  -  Job  Accounting 

c.     (,FLD-l,FLD-2, . . . ,FLD-8)  (continued) 

(3.)  When  one  field  is  used  and  preceding  fields 
are  unused,  the  absence  of  each  preceding 
field  must  be  indicated  with  a  comma,  i.e. 
if  FLD-4  is  the  only  field  used  the  optional 
accounting   information  would  appear  as 

(,,,,FLD-4) . 

MMMM.BB.NNN. . .N  identifies  the  responsible  user. 

a.  MMMM  is  the  four  digit  User  Number  assigned  by 
the  Information  Services  Division.  This  is  a 
reguired  field. 

b.  BB  identifies  the  Output  Box  Number  for  dis- 
tributing output  printed  on  ISD  printers.  It  is 
an  optional  field,  but  should  be  coded  to  insure 
distribution. 

c.  NNN...N  is  an  optional  field  up  to  eight 
characters  in  length  that  may  be  used  for  the 
user's  name. 


The  current  valid  keyword  parameters  and  their 
defaults  and  limits  are  listed  in  Appendix  D  -  JOB 
STATEMENT  -  KEYWORD  PARAMETERS. 
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SETUP  statement  format 

/*SETUP  999999 ,999999, 999999, etc. 

or 
/*SETUP  DSN=XXX.XXXX.XXX(+0) 

1.  ISD  requires  a  SETUP  statement  be  used  in  all  jobs 
which  will  request  the  mount  of  a  specific  tape.  The 
absence  of  this  statement  may  cause  the  job  to  be 
canceled.  The  manner  in  which  ISD  employs  this 
statement  is  somewhat  different  than  described  in  the 
MVS  JCL  manual.  These  differences  are  explained 
below. 

a.  The  use  of  the  SETUP  statement  does  not  cause 
the  job  to  be  placed  in  hold  status. 

b.  Either  the  volume  serial  number  of  a  tape  or  the 
dataset  name  (of  a  cataloged  dataset)  may  be  used 
to  identify  the  requested  volumes.  These  two 
methods  of  codinq  the  SETUP  statement  are 
illustrated  in  the  examples  above. 

EXEC  Statement  keyword  parameter  defaults  and  correct 
values  are  listed  in  Appendix  D  -  EXEC  STATEMENT  -  KEYWORD 
PARAMETER  DEFAULTS. 


DD  Statement  keyword  parameter  defaults  and  correct  values 
are  listed  in  Appendix  D  -  DD  STATEMENT  -  KEYWORD  PARAMETER 
DEFAULTS  AND  VALUES. 
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Job  Control  Language  Guidelines 

Job  Control  Language  (JCL)  should  be  developed  for  ease  of 
maintainability.  The  following  conventions  should  be  consider 
for  all  JCL,  whether  one  time  jobs  or  production  job  stream. 

A.    Catalog  procedures 

1.  Develop  JCL  using  catalog  procedures.  Catalog 
procedures  should  be  stored  in  agency  or  system 
procedure  libraries. 

2.  Design  all  procedures  to  allow  use  for  both  test  and 
production  processing  (see  symbolic  parameters) . 

3.  Vertically  align  parameters  as  necessary  to  improve 
readability. 

4.  Use  symbolic  parameters  and  supply  defaults  whenever 
useful . 

a.  On  the  PROC  statement  code  one  symbolic  parameter 
per  line.  Give  a  short,  explanatory  comment  for 
each. 

b.  Use  ' &PGMNAME1  on  the  EXEC  statement. 

c.  Use  '&SUF'  appended  to  the  third  node  of  the  DSN 

5.  Use  condition  code  checking  to  control  step  execution. 
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B.    JCL  Format  should  be  consistent  throughout. 

1 .  Comments . 

a.  Place  a  Procedure  Comment  Block  after  the  ' PROC * 
card  to  identify  the  procedure  (use  TSO  wild 
card) .   Include  the  following: 

System  Name 

Proc  Name 

Proc  Title  and  Description 

Example  Execute  JCL 

Restart  Instructions 

b.  Place  a  Step  Comment  Block  after  the  'EXEC  card 
to  identify  the  step  (use  TSO  wild  card) .  Place 
the  Step  Comment  Block  after  the  'EXEC  state- 
ment.  Include  the  following: 

Program  Number 

Program  Title 
°     Program  Description 
°     If  the  program  has  a  sort,  identify  the  sort 

fields  and  indicate  if  the  field  is  sorted 

ascending  or  descending. 

2.  Use  the  program  name  as  the  step  name. 

3.  DD  statements  should  appear  in  the  following  order  in 
each  step: 

a.  STEPLIB 

b.  SYSOUT 

c.  SYSDBOUT 

d.  SYSUDUMP 

e.  SORTMSG 

f.  SYSIN 

g.  SORTWK'S 
h.  xDMS  FILES 

i.  'I'  DD  STATEMENTS  (INPUTS) 

j.  '0'  DD  STATEMENTS  (OUTPUTS) 

k.  'R'  DD  STATEMENTS  (REPORTS) 

1 .  CPXMRPTS 

m.  CPXTIMSV 

n.  CPXMOPTS 
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JCL  Format  (continued) 

4.    Code  DD  parameters  one  per  line,  vertically  aligned 
starting  in  position  16  in  the  following  order: 

a.  DSN   (Code  the  DSN  text  name  in  the  right  margin) 

b.  DISP 

c.  UNIT 

d.  VOL 

e.  LABEL 

f .  DCB 

g.  SPACE 

DD  keyword  use. 
1.    DSN  - 

a.  Only  use  '&&'  DSN's  for  temporary  datasets  used 
only  by  a  single  job  step. 

b.  '  DD  * '  must  be  included  in  the  step  as  a  '  DD 
DUMMY1  with  the  • DD  * •  override  statement  placed 
in  the  execute  JCL. 

c.  Assign  a  system  Dataset  name  SN  (FNN. SS .X. A99) 
for  all  datasets  except  those  used  by  a  single 
job  step. 

d.  Code  symbolic  names  for  generation  levels  of 
generation  datasets  to  allow  ease  of  restart. 

f.  Use  dataset  refer-backs  when  possible.  Refer  to 
the  step  in  which  a  dataset  was  most  recently 
used. 

g.  Comment  the  dsn  statement  to  identify  the  dataset 
being  used  and  how  the  dataset  is  being  used  (I, 
0,  or  I/O) . 
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DD  keyword  use.  (continued) 
2.    DISP 

a.  Always  use  3  DISP  parameters. 

b.  Catalog  all  datasets. 

1)  Use  generation  data  groups  for  all  tape 
datasets. 

2)  Delete  temporary  datasets  in  a  final  IEFBR14 
step  or  throughout  the  job  after  they  are 
no  longer  needed  for  restart. 


3 .  VOL  -  Use  the  RETAIN  subparameter  if  creating  a  tape 
that  will  be  used  in  a  subsequent  step. 

4.  DCB 

a.  Use  efficient  dataset  blocking  factors.  Make 
them  as  high  as  possible  with  consideration  for 
excessive  REGION  SIZE. 

b.  Code  RECFM,  LRECL,  and  BLKSIZE  subparameters  for 
all  output  datasets. 

c.  Use  dataset  refer-backs  when  possible.  Refer  to 
the  step  in  which  a  dataset  was  most  recently 
used. 

5.  SPACE 

a.  Code  'RLSE*  on  all  space  allocations. 

b.  Do  not  use  symbolic  parameters  for  SYSDA  space 
allocations  unless  special  circumstances  require 
their  use.  Code  a  secondary  allocation  to 
provide  for  unanticipated  growth.  Code  space  in 
blocks  not  cylinders  or  tracks. 

6.  Define  SYSOUT  to  paper  different  than  the  JCL. 

7.  DEST  -  Code  '  DEST=CENTRAL'  on  all  'SYSUDUMP'  state- 
ments. 
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Execution  JCL 


JOB  card 


a.  JOBNAME  -  the  optional  SSSSSS  should  include 
either  the  User  Number  of  the  person  responsible 
for  the  job  or  other  information  which  can  be 
used  to  identify  the  job. 

b.  USERID  -  user  number  should  always  be  the  number 
of  the  individual  or  function  responsible  for 
tape  management  for  the  system  (all  tapes  will 
appear  under  this  number) . 

c.  BOX  NUMBER  -  should  always  be  coded. 

d.  USER  NAME  -  should  be  the  name  of  the  person 
responsible  for  input/output  control  of  the 
production  job. 

/*R0UTE  -  use  /*R0UTE  PRINT  CENTRAL  for  all  production 
procedures. 
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I.  Mainframe  Applications 

A.  Only  software  products  that  are  supported  by  the  Inform- 
ation Services  Division  will  be  used  for  developing  new  or 
enhancing  existing  mainframe  application  systems. 

B.  Appendix  B  contains  a  list  of  supported  mainframe  software 
products. 

II .  Microcomputer  Applications 

A.  Only  software  products  that  are  supported  by  the  Inform- 
ation Services  Division's  Information  Center  Bureau  will 
be  used  for  developing  new  or  enhancing  existing  micro- 
computer applications  that  are  statewide  in  scope  and 
supported  by  the  Department  of  Administration. 

B.  Appendix  C  contains  a  list  of  supported  microcomputer 
application  software. 
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I .  Introduction 

The  COBOL  Coding  Guidelines  presented  in  this  section  are 
suggested  for  use  in  the  development  of  COBOL  programs.  The 
purpose  of  having  guidelines  is  to  provide  a  common  set  of  con- 
ventions for  developing  and  documenting  COBOL  programs. 

II .  General  Coding  Considerations 

A.  Comments  -  Use  the  Asterisk  (*)  in  column  7  for  program 
notations  and  comments.   The  NOTE  verb  should  not  be  used. 

B.  Indentation  -  All  indentations  in  the  program  should  be  2 
or  more  spaces. 

C.  Program  Listings  -  The  eject  statement  should  be  used 
between  divisions  and  between  large  modules  in  the 
procedure  division.  The  skip  statement  or  blank  lines  can 
be  used  between  paragraphs  or  sections  of  a  module  to 
improve  readability. 

D.  Alignment  -  Vertically  align  like  items  within  the  program. 
For  example,  in  the  Data  Division: 

01   RPT-REPORT-FIELDS 

05   RPT-LINE-COUNTER  PIC  S9(3) 

05   RPT-PAGE-COUNTER  PIC  S9(5) 

05   RPT-PAGE-TOTAL  PIC  S9(5)V99 

in  the  Procedure  Division: 


MOVE  EMPLOYEE-NAME 
MOVE  NET-PAY 
MOVE  ZERO 


TO  RPT-EMPLOYEE-NAME 
TO  RPT-NET-PAY 
TO  TOTAL-GROSS 

TOTAL-FICA 

TOTAL-TAX 
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E.  Identification  Division 

Author.  Must  be  present  with  the  name  of  the  original 
author  of  the  program. 

Name.  Include  the  title  of  the  program  after  the  Program 
Name  for  documentation. 

Date  Written.  Must  be  present  with  the  month  and  year  that 
unit  testing  of  the  original  program  was  completed.  This 
field  is  not  updated  for  program  changes. 

Date  Compiled.  Must  be  present.  This  field  is  left  blank 
and  filled  in  by  the  compiler. 

Remarks.   Must  be  present  and  shall  include: 

A  brief  description  of  the  purpose  of  this  program. 

The  programmer's  name,  date,  program  change  request 
number,  system  enhancement  request  number  and  a  brief 
description  of  the  change  made. 

F.  Environment  Division 

Select  Statement.  Use  the  file-status  clause  for  all  VSAM 
files.   For  example: 

Select  VSAM-FILE  Assign  to  DA-DDNAME 
File-status  is  VSAM-STATUS 

Alignment.  Vertically  align  Select,  Assign,  and  External 
DDNAME  clauses.   For  example: 

Select  Update-Trans-File  Assign  to  UT-S-I00675D1. 

Select  Master-File       Assign  to  UT-S-I00675M1. 

Select  Update-Register    Assign  to  UT-S-RP123401 . 
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Environment  Division  (continued) 

Assign  Clause.  In  the  Assign  Clause,  all  standard 
sequential  files  must  specify  utility  in  the  device  class 
parameter  (I.E.,  UT-S-DDNAME) .  The  DDName  may  have  one  of 
two  formats.   The  format  for  report  files  is:   RP  XXXXX  X 

where 

Level  Description 

RP:  Abbreviation  for  report 

XXXXX:  Program  Number 

X:  Consecutive  Number  (1-9) 

The  format  for  non-report  files  is:  A  BB  CCC  D  E 

where 

Level  Description 

A:  File  Usage 

I  -  input 
0  -  output 
W  -  work 

BB:  Agency  Number* 

CCC:  System  Number* 

D:  Type  of  file* 

E:  Consecutive  Number  (1-9)* 

*  Agency  number,  system  number,  type  of  file  and 
consecutive  number  should  correspond  to  these 
elements  in  the  dataset  name.  (Refer  to  file 
definition  procedures.) 
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Data  Division 

Record  Contains.    The  Record  Contains  clause  must  be 
specified  for  all  FD's  and  SD's. 


Block  Contains, 


"Block  Contains  O  Records"  must  be 


specified  for  all  standard  sequential  files,  including 
report  files. 

Prefixing.  Assign  a  reasonable  prefix  to  each  level  01 
item  in  the  program  and  use  this  prefixing  on  every 
subordinate  data  item  (except  filler) .  Alphabetizing 
working  storage  group  items  is  recommended. 

Data  Names.  Use  Data  Names  that  are  clear,  descriptive, 
and  meaningful.   For  example,  use: 

MF-ACCOUNTING-ENTITY  not  MF-A-E. 

Use  consistent  abbreviations  throughout  a  program  and  a 
system.  When  possible,  use  established  abbreviations. 
Refer  to  Element  Name  Abbreviation  List  in  the  Adminis- 
trative file. 

Separate  the  logical  parts  of  data  names  with  hyphens. 
For  example,  use  MF-NET-PAY  rather  than  MFNETPAY,  or 
OUTPUT-RECORD  rather  than  OUTPUTREC. 

Alignment.  Vertically  align  PICTURE,  VALUE,  and  USAGE 
CLAUSES.   For  example: 


01    WC-CONSTANTS 

05    WC-NBR-DAYS 
05    WC-NBR-MONTHS 
05    WC-MAX-AMOUNT 
05    WC-YEAR 


PIC  S9(3) 

PIC  S9(3) 

PIC  S9(5)V99 

PIC  X(4) 


VALUE  +3  65 

VALUE  +12 

VALUE  +1000.00 

VALUE  ' YEAR • 


Use  PIC  X(4)  rather  than  PIC  XXXX,  PIC  9(7)V  9(5)  rather 
than  PIC  9999999V9999. 
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G.    Data  Division  (continued) 

Constants.  All  data  items  that  remain  constant  through- 
out a  program,  but  are  subject  to  change,  must  be  defined 
in  a  value  clause  in  the  Data  Division.  For  example,  in 
the  Data  Division: 

01  MF-FICA-RATE      PIC  S9V99       VALUE  +5.8  5 
and  in  the  Procedure  Division: 

COMPUTE  MF-FICA-TAX  =  (MF-GROSS  *  MF-FICA-RATE) 
rather  than: 

COMPUTE  MF-FICA-TAX  =  (MF-GROSS  *  5.85) 

Numeric  fields.  All  numeric  data  that  is  to  be  used  in 
computations  must  be  signed;  all  comp-3  fields  must  be 
signed  and  should  be  an  uneven  size  (i.e.  1,  3,  5...) 

77  Level.  Level  77's  are  not  allowed,  structure  related 
data  items  under  separate  level  01  entries.   For  example: 

01    WM-MESSAGE 

05  WM-ABEND-MSG  PIC  X(5)  VALUE  'ABEND1. 

05  WM-NORMAL-END  PIC  X(3)  VALUE  ■ EOJ ' . 
01    WGC-GLOBAL-COUNTERS 

05  WGC-PAGE-NUMBER  PIC  S99. 

05  WGC-LINE-NUMBER  PIC  S99. 

05  WGC-RECORD-NUMBER  PIC  S99. 

Subordinate  Entries.  All  subordinate  01  data  description 
entries  are  to  be  indented  and  incremented  consistently. 

For  example: 

01    INPUT-RECORD. 

05  INPUT-RECEIVED-DATE. 

10  INPUT-RECEIVED-MONTH  PIC  99. 
10  INPUT-RECEIVED-DAY  PIC  99. 
10  INPUT-RECEIVED-YEAR   PIC  99. 
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G.    Data  Division  (continued) 

Tables.  Loading  records  from  a  database  into  a  table  for 
subseguent  table  search  should  not  be  done  unless  perfor- 
mance is  an  issue. 

Condition  Names  -  Level  88.  Level  88' s  with  a  meaningful 
condition  names  are  to  be  used  in  logical  tests  rather  than 
literals  whenever  level  88 's  will  increase  ease  of 
understanding . 


01 


MF-SEX-CODE 
88  MALE 
88  FEMALE 


PIC  X. 
VALUE  'M1 
VALUE  'F' 


And  in  Procedure  Division: 

use  IF  FEMALE 

rather  than  IF  MF-SEX-CODE  =  'F' 

Exception:   Condition  names  for  IDMS  data  elements  must 
follow  Database  Administration  naming  conventions. 

Procedure  Division 

General  Logic. 

A  program  should  have  one  entry  and  one  exit  point. 
The  Procedure  Division  should  have  three  or  four 
PERFORM  statements:   PERFORM  A-HOUSEKEEPING,  PERFORM 
B-MAIN,  AND  PERFORM  C-TERMINATE  or  PERFORM  A-HOUSE- 
KEEPING, PERFORM  B-SORT-INPUT,  PERFORM  C-SORT-OUTPUT, 
AND  D-TERMINATE  for  programs  with  an  internal  sort. 
A  program   should  be   structured   using   performed 
paragraphs  rather  than  repeating  sections  of  code. 
Database   retrieval,   update   commands   should   be 
performed  rather  than  having  multiple  commands  for 
the  same  function  for  the  same  record. 


Accept  Verb.   The  'from  console'  option  of  the  accept  verb 
is  discouraged  and  should  only  be  used  in  special  cases. 

Alter  Statement.   The  ALTER  verb  is  not  allowed. 
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H.    Procedure  Division  (continued) 

Dates.  Use  DATECVT  to  get  the  current  date  or  to  perform 
other  date  related  functions.  DATECVT  is  supported  by  and 
documentation  is  available  from  the  Department  of  Ad- 
ministration, Information  Services  Division,  Technical 
Services  Section.  Do  not  use  ACCEPT  to  obtain  system 
dates. 

Display  Verb.  The  'UPON  CONSOLE'  option  of  the  DISPLAY 
verb  is  discouraged  and  should  only  be  used  in  special 
cases.  All  new  systems  should  use  job  status  reporting 
with  minimal  or  no  Display  use. 

Record  Initialization.  All  records  should  be  initialized 
at  the  field  level  unless  every  field  is  of  the  same  data 
format  (and  very  likely  to  stay  that  way!). 

VSAM  Status.  Interrogate  the  FILE-STATUS  indicator  on 
every  VSAM  file  access. 

GO  TO.  GO  TO  statements  should  be  eliminated  as  much  as 
possible.  There  are  three  cases,  however,  where  use  of  a 
GO  TO  may  produce  more  understandable  code  than  overly 
nested  IF's  or  other  convoluted  logic. 

1.  A  GO  TO  DEPENDING  ON  can  be  used  in  place  of  nested 
IF  statements  for  a  CASE  construct  with  more  than 
just  a  few  cases.   For  example: 


GO  TO  EDIT-FIELD1, 
EDIT-FIELD2, 
o 
o 
o 

EDIT-FIELDn 

DEPENDING  ON  FIELD-NUMBER 
EDIT-FIELD1. 
o 
o 
o 
GO  TO  EDITS-EXIT. 
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Procedure  Division  (GO  TO,  1.  continued) 

EDIT-FIELD2. 

o 

o 

o 

GO  TO  EDITS-EXIT. 

o 

o 

o 
EDIT-FIELDn. 

o 

o 

GO  TO  EDITS-EXIT. 

o 

o 

o 

2 .  In  order  to  branch  to  the  end  of  a  procedure  without 
leaving  the  procedure  and  thus  return  control  to  the 
statement  following  a  PERFORM  for  that  procedure,  use 
the  THRU  option  of  the  PERFORM  and  then  GO  TO  the  end 
of  the  procedure  as  in  the  following  example: 

PERFORM  SETUP1  THRU  SETUP1-EXIT 

o 

o 

o 

SETUP1 

READ  IN-FILE  INTO  IN-RECORD 

AT  END  GO  TO  SETUP1-EXIT. 
MOVE  IN-RECORD  TO  OUT-RECORD. 

MOVE  SPACES  TO  IN-RECORD. 
SETUP1-EXIT.   EXIT. 


3.  A  third  valid  use  for  a  GO  TO  would  be  to  branch  to 
an  end-of-program  paragraph  immediately  following  the 
main  driver  module  whenever  a  serious  ABEND  condition 
arises  in  the  program. 

Also,  GO  TO ' s  may  appear  in  a  CICS  routine  where  they  may 
be  generated  by  CICS  macros. 
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Procedure  Division  (continued) 

Boolean  Operators.  The  words  GREATER  THAN  and  LESS  THAN 
are  to  be  used  rather  than  symbols. 

IF  Statements.  Successive  levels  of  nested  IF  Statements 
must  be  indented  consistently.  An  ELSE  Clause  must  be 
aligned  with  its  corresponding  IF  statement  and  must  be  on 
a  line  by  itself.   For  example  use: 

IF  STATE  EQUAL  MONTANA 
ADD  1  TO  RESIDENT 
IF  COUNTY  EQUAL  YELLOWSTONE 

ADD  1  TO  NUMBER-SELECTED 
ELSE 

NEXT  SENTENCE 
ELSE 

ADD  1  TO  NON-RESIDENT 

Be  aware  of  constructs  available  to  avoid  overly  compli- 
cated nested  IF's  such  as  the  GO  TO  DEPENDING  ON. 

Paragraph  and  Section  Names.  Each  paragraph/section  name 
must  appear  on  a  line  by  itself. 


Perform  Statements, 


The  values  of  the  loop  control 


variables  associated  with  the  VARYING  and  BY  phrases  of  a 
PERFORM  Statement  may  not  be  modified  within  the  performed 
procedure.  Indent  and  align  the  VARYING  and  UNTIL  Clauses. 
For  example,  use: 

PERFORM  Bl-MAIN-LOGIC 
VARYING  INDEX 
FROM  1  BY  1 
UNTIL  INDEX  GREATER  THAN  10 


PERFORM  Bl-MAIN-LOGIC 
VARYING 

INDEX  FROM  1  BY  1 
UNTIL 

INDEX  GREATER  THAN  10 
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H.    Procedure  Division  (Perform  Statements  continued) 

rather  than; 

PERFORM  DRIVER-MODULE  VARYING  INDEX 
FROM  1  BY  1  UNTIL  INDEX  GREATER  THAN  10. 

Reads  and  Writes.  Only  one  READ  Statement  is  allowed  per 
type  of  file  retrieval.  Only  one  WRITE/Rewrite  Statement 
for  each  different  length  and  kind  of  output  record  is 
allowed.   This  does  not  apply  to  IDMS  commands. 

Statement  Format.  Begin  each  sentence  in  column  12  and 
end  each  sentence  with  a  period.  If  a  sentence  requires 
more  than  one  line,  indent  the  continuation.  Do  not  use 
superfluous  punctuation  (commas,  semicolons,  etc.).  Only 
one  verb  per  line  is  allowed. 

Sort  Return.  Check  SORT-RETURN  after  all  embedded  sorts 
to  verify  the  success  of  the  sort. 

Stop  Run  and  Go  Back.  There  may  be  only  one  STOP  RUN/GO 
BACK  Statement  in  each  program.  CICS  Programs  are  exempt 
from  this  standard. 

Ill .  Compiler  Considerations 

A.  Use  the  following  compiler  options  if  subprogram  linkage 
is  part  of  the  design  (on  both  calling  and  called  pro- 
grams) : 

1 .  DYNAM 

2.  RESIDENT 
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III.  Compiler  Considerations  (continued) 

B.    The  CA  Optimizer  should  be  used  for  all  COBOL  program 
development. 

1.  Programs  should  be  compiled  with  the  following  CA 
Optimizer   options: 

a.  DTECT  -  test  and  prod 

b.  XCOUNT  -  test 

c.  MLIST  -  test  and  prod 

d.  MDMAP  -  test  and  prod 

2.  All  Optimizer  compress  Source  Listings  should  be 
stored  in  a  library  allocated  for  that  purpose  by 
system,  application,  or  agency. 
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I.  Introduction 

ADS  development  guidelines  provide  a  consistent  method  of 
developing  online  systems  and  help  new  development  projects 
avoid  the  extra  expense  and  time  incurred  while  learning  a  new 
language. 

The  recommendations  that  follow  are  based  upon  the  Release  10.2 
of  Cullinet  software.  These  guidelines  will  be  updated  as  new 
enhancements,  program  fixes,  and  releases  are  installed. 

II .  General  Development  Considerations 

A.  Productivity  -  The  programmer  productivity  features  of  ADS 
should  always  be  used  unless  there  is  good  reason 
(cost/benefit)  to  use  solutions  that  require  more  person 
effort  to  develop  and  maintain.  Some  of  the  DBMS  and 
Cullinet  productivity  tools  are:  Dictionary  Module  Editor 
(DME) ,  Online  Test,  ADS/TRACE,  TP/SORT,  OLM  edit  modules, 
Built  In  Functions,  Pageable  Mapping  and  the  use  of  the 
online  IDMS  Utility  Functions  available  through  DBA01. 
Use  of  these  features  may  reduce  development  and  main- 
tenance costs. 

B.  Use  of  ADS/A  -  All  new  ADS  online  systems  should  use  ADS/A. 
ADS/A  is  a  powerful  analytical  tool  when  used  to  prototype 
systems  and  supports  development  from  the  prototype  to  a 
production  system. 

C.  Control  Commands  -  The  ADS/A  controller  allows  the  removal 
of  many  interdialog  control  commands  from  the  ADS/0  source 
code.  Keeping  the  control  commands  in  the  ADS/A  controller 
allows  system  flow  changes  to  be  completed  without  source 
code  changes  and  dialog  recompilation. 

D.  Naming  Conventions  and  Abbreviations  -  Follow  the  naming 
conventions  and  abbreviations  described  in  the  guideline 
for  Database  Design. 
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Color  -  Use  color  PC's  or  terminals  whenever  feasible. 
Colored  fields  help  the  terminal  operator  to  quickly 
distinguish  literals,  data  fields  and  fields  that  were 
incorrectly  entered.  Recommend  colors  and  system  default 
colors  are  as  follows: 


literals: 
data  fields: 
errors: 
highlighted: 


Recommended 

green 
yellow 
pink  or  red 
N/A 


System  Defaults 

green 
green 
red 
white 


The  recommended  colors  have  been  tested  in  a  high  volume 
production  environment  with  relatively  good  success.  Other 
combinations  may  be  more  suitable  to  your  application, 
however,  use  caution  when  selecting  color  combinations  as 
they  may  cause  unnecessary  eye  strain  for  the  terminal 
operator. 

Load  Module  Sizes  -  Keep  ADS/A  applications  and  ADS/O 
dialog  load  module  (FDB)  sizes  less  than  40K.  This  value 
can  be  found  on  the  ADS/O  report  and  with  the  display  load 
module  in  IDD. 


Subschema  Definitions  -  Tailor  database  subschemas  to  match 
the  information  requirements  of  each  program  or  group  of 
programs.  Subschemas  for  dialogs  that  perform  IDMS  store 
commands  should  have  the  entire  record  description  defined 
to  the  subschema. 

Menu  Control  -  Accept  any  database  key  information  and  the 
activity  (add,  change,  delete,  or  inquire)  at  the  menu 
level,  before  passing  control  to  an  update  or  inquiry 
program.  Capturing  this  information  at  the  menu  level 
greatly  reduces  complexity  of  lower  level  dialogs. 
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Dialog  Design  -  Perform  inquiry  and  update  functions  in 
separate  dialogs.  Consider  separating  the  update  functions 
ADD,  CHANGE,  and  DELETE  when  any  of  the  following  situa- 
tions exist  for  your  application: 

1.  The  edit  criteria  varies  significantly  for  each 
function. 

2.  Large  amounts  of  code  are  unique  to  each  function; 
thereby,  loaded  but  not  executed  depending  on  the 
function  requested. 

3.  The  processing  becomes  complex  and  difficult  to 
maintain. 

PF  Key  Assignments  -  Attempt  to  standardize  PF  key 
assignments  to  other  applications.   Use  the  following: 

PA1  -  Reserve  for  printing 

PF1  -  Help 

PF2  -  Pop 

PF3  -  Pop  Top 

PF7  -  Page  backward  (up) 

PF8  -  Page  forward  (down) 

CLEAR  -  To  leave  the  application 

Screen  Design  -  use  the  following  screen  design  conven- 
tions: 

o  Screen  identification  (for  support  purposes)  will 
always  be  in  the  upper  left  corner.  The  map  name 
serves  as  a  good  identifier. 

o  Screen  title  will  always  appear  centered  on  the  top 
line. 

o  System  date  and  time  will  appear  on  the  top  line  in 
the  right  corner. 

o  The  error  message  line  appears  on  the  bottom  line  of 
the  screen. 
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K.    Screen  Design  (continued) 

o     The  PF  key  descriptions  and  the  RESPONSE  field  appear 
on  the  lines  immediately  above  the  error  message  line. 

o     Pageable  screens  should  have  a  page  number. 

o     Pageable  screens  should  not  be  used  for  updates. 

L.  Map  Records  -  All  map  records  should  begin  with  the  map 
name,  followed  by  MAP-REC.   (AMTR4  000-MAP-REC) 

All  data  elements  within  a  map  record  should  be  prefixed 
with  'M'  and  the  dialog  number,  i.e.,  M4000-MEMB-SSN.  Only 
one  (1)  map  record  should  be  used  for  each  map. 

M.  Work  Records  -  All  work  records  should  be  prefixed  with 
the  dialog  name  followed  by  WORK-REC.   (AATR4  000-WORK-REC) 

All  data  elements  within  a  work  record  should  be  prefixed 
with  'W'  and  the  dialog  number,  i.e.,  W4000-MEMB-SSN.  Only 
one  (1)  work  record  should  be  defined  for  each  dialog. 

All  dialogs  will  need  to  define  the  ADSO-APPLICATION- 
GLOBAL-RECORD  as  a  work  record. 

N.  Security  -  Use  the  ADS/A  security  scheme  established  and 
maintained  by  the  Database  Design  and  Administration 
Section  of  the  Systems  Development  Bureau.  If  there  are 
more  complex,  data  dependent  requirements,  the  application 
will  need  to  provide  for  them. 

III.  ADS/A  Development  Guidelines 

A.  Function  and  Response  Design  -  When  creating  a  prototype 
or  test  application,  it  is  strongly  recommended  that  the 
function  and  response  flow  be  first  drawn  on  paper  before 
working  in  ADS/A.  When  an  acceptable  flow  has  been 
designed  define  the  responses  to  ADS/A  and  skeleton 
functions  will  be  created  by  the  system.  Application 
definition  'on  the  fly'  can  be  very  expensive  and  is  likely 
to  be  error  prone. 


POLICY: 

STANDARD: 

PROCEDURE: 

GUIDELINE: 


Management  of  Software 
Standardized  Use  of  Software 


Section  1-12301 


# 
# 
Application  Development  System  (ADS)   # 

PUB.  DATE 

REVIEW  DATE 

PAGE 


04 

02 
09/21/89 

5  OF  12 


B.  Application  Size  -  Keep  your  application  small  and 
functionally  independent.  Large  applications  (200 
responses  or  more)  are  very  difficult  to  maintain  and 
expensive  to  generate.  A  system  may  be  divided  into 
multiple  applications  without  any  user  inconvenience  by 
using  the  • LEAVE  APPLICATION  NEXT  TASK'  command.  Security 
information,  database  record  keys,  etc.,  may  be  passed  from 
one  application  to  another  through  the  use  of  SCRATCH 
records. 

C.  Mixing  ADS/O  and  ADS/A  Control  Commands  -  Do  not  mix  ADS/O 
and  ADS/A  control  commands.  ADS/A  cannot  keep  track  of 
ADS/O  control  commands.  ADS/A  will  be  pointing  to  the  last 
function  it  issued,  regardless  of  any  ADS/O  control 
commands  issued. 

D.  Transfers  -  Use  transfers  whenever  possible. 

E.  INVOKES  and  LINKS  -  If  LINKS  and  INVOKES  must  be  used,  you 
should  not  extend  more  than  three  levels.  Always  attempt 
to  extend  the  run-unit  by  using  the  same  subschema  in  both 
dialogs.  Use  the  NOSAVE  option  if  you  do  not  need 
currencies  restored. 


Nesting  -  Avoid  nesting  multiple  ADS/O  dialogs  under  one 
ADS/A  function.  In  other  words,  define  an  ADS/A  function 
for  each  ADS/O  dialog  in  your  system.  This  will  make  your 
system  much  more  visible  at  the  Application  level  and  help 
you  avoid  mixing  ADS/O  and  ADS/A  control  commands. 

Passing  Command  Information  -  The  ADSO-APPLICATION-GLOBAL- 
RECORD  should  be  used  to  pass  common  application  informa- 
tion from  function  to  function.  Create  your  own  global 
record  to  pass  information  that  is  unique  to  your  applica- 
tion. Keep  this  record  small  since  it  remains  in  storage 
as  long  as  the  application  is  executing. 

Version  Numbers  -  Always  specify  version  number  when 
defining  globcu.  records  to  an  application.  They  will  not 
work  if  omitted. 
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IV.   ADS/O  Development  Guidelines 

A.  Program  Structure  -  The  ADS/O  programming  language  lends 
itself  nicely  to  the  structured  programming  approach 
currently  used  in  COBOL.  Use  the  SUBROUTINE  CONTROL 
COMMANDS  (CALL,  DEFINE  SUBROUTINE,  and  GOBACK)  to  create 
a  modular  program.  Prefix  or  suffix  the  subroutine  names 
with  an  alphabetic  sequentially  assigned  character  to  make 
the  subroutine  easier  to  locate. 

B.  Subroutine  Documentation  -  Always  include  a  documentation 
block  before  each  subroutine.  Unlike  COBOL  the  eight 
character  subroutine  names  do  very  little  to  describe  the 
code  being  executed. 

C.  Module  Design  -  Separate  your  program  into  independent 
logic  groups  (i.e.:  data  retrieval  logic,  edit  logic,  and 
update  logic) .  Should  the  program  exceed  the  recommended 
limit  of  40K,  large  blocks  of  code  may  be  removed  from  the 
dialog,  inserted  in  a  mapless  dialog,  and  executed  via  a 
link  command. 

D.  Subroutines  -  Name  subroutines  as  close  to  COBOL  paragraph 
naming  conventions  as  possible.  Because  of  the  limit  of 
eight  (8)  characters  in  a  subroutine  name  this  may  be 
difficult  at  times.  To  make  things  easier,  use  only  one 
(1).   Hyphen  between  the  prefix  and  the  subroutine  name. 


i.e.  : 
(NOT) 


Cll-ACCT 
C-l-l-AC 


Use  subroutines  when  accessing  multiple  records.  When 
using  subroutines  in  this  manner  use  the  standard  prefix 
and  the  database  record  suffix  as  the  subroutine  name. 


C-CTSUM 
Bl-RTSEP 


Management  of  Software 
Standardized  Use  of  Software 


POLICY 

STANDARD:   Standardized  Use  of  Software  # 

PROCEDURE:  # 

GUIDELINE:   Application  Development  System  (ADS)   # 

PUB.  DATE 

REVIEW  DATE 

PAGE 


Section  1-12301 
04 


02 
09/21/89 

7  OF  12 


IV.   ADS/O  Development  Guidelines  (continued) 
D.    Editing 


1.  Use  the  OLM  edit  and  encode/decode  tables  whenever 
possible.  Do  not  link  the  tables  to  the  map,  as  this 
will  require  a  recompile  of  the  map  whenever  the  table 
is  modified. 

2  .  The  MAP  MODIFICATION  COMMANDS  and  the  MAP  FIELD  STATUS 
CONDITION  commands  in  conjunction  with  the  EXTENDED 
INITIAL  DEFINITION  SCREEN  (OLM-PF9)  are  extremely 
helpful  when  writing  edit  logic.  Use  the  MODIFY  MAP 
. . .  EDIT  IS  ERROR  command  to  flag  any  fields  that  do 
not  pass  your  edit  requirements.  At  the  end  of  your 
edit  logic,  use  the  IF  ANY  FIELDS  ARE  IN  ERROR  command 
to  verify  that  all  edits  have  been  passed  before 
performing  the  update  logic.  Specify  the  attributes 
of  the  incorrect  fields  on  the  EXTENDED  INITIAL 
DEFINITION  SCREEN  (highlight,  MDT,  and  pink  or  red  are 
recommended) .  The  attributes  for  correct  fields  will 
default  to  the  definition  of  the  data  field  and  should 
not  need  to  be  altered  in  most  applications. 

E.  Error  Handling  -  Three  different  methods  of  issuing  error 
messages  are  commonly  used.  Any  one  or  a  combination  of 
the  three  may  be  used  depending  on  the  complexity  of  the 
application  and  the  users  involved. 


1. 


A   general   error   message.     'CORRECT 
FIELDS',  'CORRECT  FIELDS  IN  RED',  etc. 


HIGHLIGHTED 


An  error  message  may  be  specified  for  each  data  field 
in  the  text  message  of  the  EXTENDED  FIELD  EDIT  SCREEN 
(PF10)  on  the  map.  The  messages  for  all  fields 
modified  EDIT  IS  ERROR  will  then  appear  in  the 
$MESSAGE  field  when  the  next  DISPLAY  command  is 
executed.  Never  use  an  apostroohe  in  the  text 
message.  The  apostrophe  will  terminate  the  batch  map 
compiler. 
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IV.   ADS/O  Development  Guidelines  (continued) 

E.  Error  Handling  (continued) 

3.  An  array  equal  to  the  size  of  the  $MESSAGE  field  may 
be  defined  in  working  storage.  Each  individual  error 
message  can  be  moved  to  the  next  available  array 
position  as  an  error  is  encountered.  At  the  comple- 
tion of  the  edit  logic  the  entire  array  should  be 
displayed.  This  method  is  similar  to  method  2,  but 
it  allows  more  specific  messages  to  be  issued  when  a 
field  is  subject  to  multiple  edits.  The  $MESSAGE 
field  length  defaults  to  80  characters  but  may  be 
altered  by  keying  the  desired  field  length  into  the 
SUB  field  on  the  field  definition  screen  in  OLM. 

F.  Online  Mapping 

1.  Use  automatic  editing  to  reduce  editing  in  the  process 
modules.  Enable  automatic  editing  for  each  field  by 
specifying  'Y1  in  the  edit  option  on  the  field  edit 
screen. 

2.  Do  not  use  the  ERASE  EOF,  INSERT,  or  DELETE  KEYS  when 
building  a  map. 

3 .  Use  the  database  records  as  map  records  for  inquiry 
screens.  In  most  cases  database  records  should  not 
be  used  as  map  records  for  update  screens. 

4.  Specify  the  delimit  as  S  (skip)  or  Y  (yes)  on  all  data 
fields.  N  (no)  is  the  default  and  will  allow  entry 
of  data  beyond  the  end  of  the  field. 


Do  not  use  the  REQUIRED  Indicator  on  the  EXTENDED 
FIELD  EDIT  SCREEN  (PF10).  It  requires  entry  into  the 
field  after  every  screen  display  whether  the  field  is 
correct  or  incorrect. 
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IV.   ADS/O  Development  Guidelines  (continued) 


Online  Mapping  (continued) 

6.  Always  specify  that  the  MDT  should  be  set  on  for  all 
fields  in  error  (EXTENDED  INITIAL  DEFINITION  SCREEN) 
to  insure  that  incorrect  fields  are  re-edited.  The 
modified  data  tag  (MDT)  indicates  whether  or  not 
information  has  been  entered  into  a  specific  field. 
This  indicator  can  be  tested  and  altered  in  the 
program  logic.  Use  this  indicator  to  test  that  a 
field  has  been  entered  or  changed  before  subjecting 
it  to  numerous  (possibly  unnecessary)  edits.  The 
modified  data  tag  is  reset  with  each  DISPLAY,  and 
should  not  be  used  to  determine  whether  a  field  should 
be  updated  on  the  database.  Two  or  more  displays  of 
the  same  screen  may  be  necessary  before  an  entire 
screen  of  information  is  correct.  Only  the  last 
fields  entered  will  have  their  modified  data  tags 
turned  on.  A  more  reliable  method  is  to  compare  the 
map  field  to  the  database  field. 

7.  A  pad  character  should  be  specified  for  all  alpha- 
numeric data  fields  and  the  zero  option  on  all  numeric 
fields.  During  a  data  entry  session,  if  the  erase  end 
of  field  key  (EOF)  is  pressed  in  a  data  field,  the 
attributes  of  the  field  will  be  set  to  MDT  on,  LENGTH 
=  -1.  If  a  pad  character  or  the  zero  option  is  not 
specified  for  a  data  field,  nothing  will  be  passed  to 
the  map  field  on  output  and  the  field  will  contain  the 
same  information  that  was  previously  mapped  out. 

8.  When  prototyping,  define  each  field  separately  to 
allow  for  easier  definition  of  data  fields  at 
development  time. 
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IV.   ADS/O  Development  Guidelines  (continued) 

G.  Paging  -  Use  the  pageable  map  facility  in  OLM  whenever 
possible.  As  of  this  writing  (August  1989)  it  is  not 
advisable  to  use  this  facility  to  update  the  database. 

SCRATCH  records  are  extremely  helpful  if  the  pageable  map 
facility  is  not  used.  Write  each  map  record  as  it  is  built 
to  the  SCRATCH  area  using  the  page  number  as  the  RECORD  ID. 
When  the  terminal  operator  requests  the  previous  page, 
subtract  one  from  the  current  page  and  retrieve  the  page 
from  the  scratch  area.  All  information  displayed  on  the 
map  must  be  defined  in  a  map  record. 

H.  88  Levels  -  Do  not  use  multiple  values  in  an  88  level 
condition  statement;  ADS/O  will  only  recognize  the  first 
occurrence. 


I.  READY  Command  -  Do  not  use  the  PROTECTED  or  EXCLUSIVE 
options  of  the  READY  command  unless  absolutely  necessary. 
These  may  cause  data  contention  problems  when  multiple 
terminal  operators  try  to  access  the  same  information. 
Ready  each  area  individually. 

J.    Source  Code  Editor  -  Use  DME  for  source  code  editing. 

K.    Integrated  Data  Dictionary  (IDD) 

1.  Use  the  DELETE/ADD  commands  to  change  edit  tables  or 
code  tables  when  using  in  IDD. 

2.  Use  the  MODIFY  commands  to  change  ADS/O  source  code 
when  using  IDD.  This  method  is  significantly  cheaper 
than  the  DELETE/ADD. 

3.  Do  not  press  PF6  when  using  the  online  IDD  editor 
until  you  are  ready  to  update  the  module,  record,  etc. 

L.  Leading  Zeroes  -  Be  aware  that  ADS/O  moves  will  replace 
leading  zeroes  with  spaces  and  right  justify  when  moving 
a  numeric  field  to  an  alpha  field.  COBOL  moves  are  the 
default. 
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IV.   ADS/0  Development  Guidelines  (continued) 

M.  $MESSAGE  -  Be  aware  that  only  the  $MESSAGE  field  will  be 
transmitted  to  the  map  when  one  or  more  fields  are  MODIFIED 
EDIT  IS  ERROR.  Fields  that  are  flagged  in  error  will  be 
altered  as  specified  on  the  EXTENDED  INITIAL  DEFINITION 
SCREEN  (PF9) .  All  other  fields  will  remain  as  they  were 
on  the  last  DISPLAY. 

N.  Use  of  Periods  -  Always  complete  a  DO  or  REPEAT  command 
with  a  period.  The  ADS/O  compiler  will  not  issue  a  syntax 
error  when  the  period  is  omitted,  but  the  compiler  may  not 
interpret  the  commands  correctly. 

0.  INITIALIZE  Command  -  Use  the  INITIALIZE  command  to  clear 
a  database,  map,  or  work  record  instead  of  MOVE  commands. 
ADS  initializes  records  used  by  the  dialog  except  if  the 
record  is  specified  at  a  higher  level  (invoke  or  link)  or 
the  dialog  uses  a  display  continue. 

P.  AUTOSTATUS  Command  -  Use  AUTOSTATUS  (the  default)  to  check 
your  database  record  status.  Use  the  ALLOWING  ERROR  CODES 
extension  of  the  database  commands  to  check  for  status 
codes  not  specified  in  the  AUTO-STATUS  record. 

Q.  Version  Numbers  -  Specify  the  version  number  of  the  dialog, 
records,  and  processes  when  adding  or  maintaining  dialogs 
in  the  Application  Development  System  Generator  (ADSG) . 
The  ADS/O  report  program  has  trouble  locating  the  source 
code  for  some  of  the  response  processes  when  version  is 
omitted. 

R.  EXECUTE  ON  EDIT  ERRORS  Prompt  -  The  EXECUTE  ON  EDIT  ERRORS 
prompt  on  the  RESPONSE  PROCESS  DEFINITION  SCREEN  of  ADSG 
should  be  set  to  NO  (the  default)  in  most  response 
processes.  This  will  keep  invalid  data  from  being  passed 
to  the  map  record.  YES  should  only  be  used  to  allow  the 
terminal  operator  to  exit  the  application. 

S.  EOF  Key  -  To  allow  use  of  the  erase  end  of  field  key  (EOF) 
in  a  field  that  is  edited  by  an  edit  or  code  table,  define 
1 ■  as  a  valid  table  entry. 
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IV.   ADS/O  Development  Guidelines  (continued) 

T.  PRODUCTION  MIGRATION  -  Use  the  MIGRATE  selection  in  DBA01 
to  migrate  dialogs,  maps,  tables  and  applications  to 
production.  Turn  the  Symbol  Table  and  Diagnostic  Tables 
off  before  migrating  dialogs  to  proauction. 
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I .  Introduction 

Source  code  for  all  production  software  (COBOL,  ADS,  CULPRIT) 
should  be  maintained  in  PANVALET. 

II .  Procedures 

A.  COBOL  programs  -  The  procedures  to  be  used  when  develop- 
ing or  modifying  a  program  are  detailed  below.  This 
section  includes  all  procedures  necessary  for  a  program 
that  had  previously  been  placed  into  production.  For  new 
program  development,  disregard  all  steps  that  do  not  apply. 

Check  the  current  daily  Panvalet  listing  for  versions 
other  than  production  or  disabled. 

Copy  the  production  version  to  a  test  version  in 
Panvalet  (SPF  8.5) . 

Retrieve  the  test  version  from  the  Pan  Library  to  your 
SPF  Library  (SPF  8.1). 

Apply  the  program  changes  as  required  by  the  Program 
Change  Request  (PCR) . 

Store  the  new  test  version  in  the  Pan  Library  (SPF 
8.2).  Always  compile  from  this  copy,  not  the  SPF 
library  copy. 

If  at  any  time  during  the  course  of  modifying  a 
program  it  is  determined  that  the  changes  should  not 
be  implemented,  rename  the  program  to  a  disable  suffix 
and  disable. 

Obtain  test  output  approval  from  Unit  Leader  and 
Customer. 

Rename  the  production  version  to  a  disabled  version 
and  disable  (SPF  8.8  Rename;  SPF  8.4  Change). 
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COBOL  programs  (continued) 

Rename  the  test  version  to  the  production  version  and 
change  the  status  to  prod  (SPF  8.8  Rename;  SPF  8.4 
Change) . 

For  all  panvalet  operations,  be  sure  to  update  the 
panvalet  user-ID  with  your  man  number  or  the  project 
man  number  (SPF  8.4  Change). 

Be  sure  the  comment  record  is  correct  (SPF  8.4 
Change) .  (Always  use  the  TSO  CLIST  to  assure  a 
comment  record  is  added  with  every  new  program.) 

Always  verify  that  each  panvalet  command  completes 
successfully. 

Status  should  be  changed  to  inactivate  on  panvalet 
and  the  comments  changed  to  reflect  its  inactive 
status  for  one  time  programs  or  removal  of  programs 
from  a  system. 

Culprit  programs  -  Production  status  culprit  source  code 
will  be  maintained  in  PANVALET  using  the  source  code 
maintenance  procedures  outlined  for  COBOL  source  code.  A 
Culprit  procedure  has  been  developed  that  retrieves  the 
PANVALET  source  as  input  to  the  Culprit  process. 

ADS  modules  -  Use  the  PANVALET  version  of  the  migration 
software  to  migrate  dialogs,  maps,  and  tables. 

Non-Database  File  Descriptions  -  A  PANVALET  file  layout 
must  be  available  for  any  file  that  is  passed  from  one 
program  to  another. 
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III ,  Naming  Conventions 

A.  PANVALET  Libraries  should  follow  one  of  the  following 
conventions: 

FNN.PANLIB  -  where  NN  is  the  agency  node 

FNN.SSS.PANLIB  -  where  NN  is  the  agency  node  and  SSS  is 
the  system  mnemonic.  This  option  is  advisable  when 
security  of  source  code  is  desireable  at  the  system  level 
rather  than  the  agency  level . 

B.  Batch  Programs  -  Use  the  full  ten  (10)  bytes  allowed  to 
uniguely  identify  each  program  and  its  status.  There  are 
four  (5)  levels  established,  each  of  which  identifies  the 
function  of  the  program.   The  structure  is  as  follows: 

SSSXYZZZSF     where: 

SSS:  Major  system  identifier  (CSE,  PPP,  DWC,  SBS, 

etc) 

X:  Subsystem  Identifier  (l=Personnel ,  2=Pay- 

roll,   3=Position  Control) 

Y:  Function  Identifier  (0=Temporary,  l=Control, 

2=Edits,  3=Updates,  4=Interfaces,  5=Reports, 
6=Sorts,  7=Misc. ,  8=System  Support 

ZZZ:  Program  Identifier  -  unique  number  within 

the  first  three  levels 

SF:  Suffix  (see  suffix  conventions  below) 

C.  Online  Programs  (and  components)  -  All  ADS  components 
should  follow  the  conventions  identified  in  Section  7  of 
the  ADS  Application  Design  Guide. 


POLICY: 

STANDARD: 

PROCEDURE: 

GUIDELINE: 


Management  of  Software 
Standardized  Use  of  Software 


Section  1-12301 


# 
# 
PANVALET  (Source  Code  Maintenance)     # 

PUB .  DATE 

REVIEW  DATE 

PAGE 


04 

03 
09/21/89 

4  OF  5 


III.  Naming  Conventions  (continued) 

D.    Subroutines   -   Subroutine   members 
following  naming  conventions: 


E. 


should   follow   the 


SSXXXXXXSF 
SS: 

XXXXXX: 
SF: 


where: 

Major  system  identifier  (CS,  PP,  DW,  SB, 
etc.) 

Subroutine  identifier  -  unique  identifier 
with  some  meaning  if  possible  (DTERR  -  Date 
Error  routine,  WJOBST  -  working  storage  data 
elements  group  job  status  routine) 

Suffix  (see  suffix  conventions  below) 


File  Layouts  -  File  layout  members  should  follow  the 
following  naming  conventions: 


SSXYYYYYSF 
SS: 

X: 

XXXXX: 


where: 

Major  system  identifier  (CS,  PP,  DW,  SB, 
etc) 

Unique  character  assigned  within  major 
system  to  designate  file  definitions  from 
all  other  panvalet  includes  (F  -  File 
Definitions,  R  -  Record  Definitions) 

Subroutine  identifier  -  unique  identifier 
with  some  meaning  if  possible  (DTERR  -  Date 
Error  routine,  WJOBST  -  working  storage  data 
elements  group  job  status  routine) 


SF: 


Suffix  (see  suffix  conventions  below) 
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III.  Naming  Conventions  (continued) 

F.    Suffix  -  In  all  cases  (COBOL  source  code,  subroutines,  file 
layouts)  use  one  the  following: 

-  (Production).  The  final,  tested  version  of  a  program 
should  be  renamed  to  the  associated  program  number 
(with  no  suffix)  to  indicate  that  the  program  has  been 
placed  into  a  production  status. 

Tn  -  (Test) .  All  new  programs  that  are  under  development 
or  existing  programs  that  are  undergoing  modifica- 
tions should  carry  a  'T'  suffix.  The  'T'  suffix 
should  not  be  used  for  production  processing.  In  some 
instances,  multiple  versions  will  have  to  exist  at  the 
same  time.  In  this  case,  use  'n'  to  distinguish  the 
multiple  version  (1-9). 

Dn  -  (Disabled) .  A  program  that  is  no  longer  needed  sho- 
uld carry  a  'D'  suffix.  A  disabled  program  is  of  no 
further  use  and  can  be  moved  to  the  Panvalet  Disabled  Tape 
where  it  is  subject  to  a  physical  delete  from  the  Panvalet 
System.  In  some  instances,  multiple  versions  will  have  to 
exist  at  the  same  time.  In  this  case,  use  'n'  to  distin- 
guish the  multiple  version  (1-9) . 

Pn  -  (Prototype) .  A  program  that  is  in  development  under 
a  prototyping  method.  The  'n'  can  be  used  to  note 
the  level  of  the  prototype  (PI  -Level  1  Prototype,  P2 
-  Level  2  Prototype) . 
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I .  Introduction 

JCL  procedures  for  all  production  applications  systems  should 
be  maintained  in  EASYPROCLIB  procedure  libraries. 

II .  Naming  Conventions 

A.  JCL  Procedure  Libraries  should  follow  one  of  the  following 
conventions: 

FNN.UPROCLIB  -  where  NN  is  the  agency  node 

FNN.SSS.UPROCLIB  -  where  NN  is  the  agency  node  and  SSS  is 
the  major  system  identifier.  This  option  is  advisable  when 
security  of  the  catalog  procedure  is  desireable  at  the 
system  level  rather  than  the  agency  level. 

B.  Procedure  Library  members  -  Use  the  full  eight  (8)  bytes 
to  uniguely  identify  each  procedure  and  its  status. 

SNNXXXY1   where: 

S:  Designates  status  (P  -  Production,  T  -  Test, 

D  -  Disable) 

NN:  Numeric  portion  of  the  agency  node  (00  - 

ISD,  01  -  Accounting,  05  -  Health) 

XXX:  Unigue  assignment  to  categorize  procedures. 

If  the  system  is  heavily  cyclic  use  the 
following: 

100  -  Daily 

110  -  Weekly 

120  -  Monthly 

140  -  Annual-Fiscal  Year 

150  -  Annual-Calendar  Year 

160  -  Request  Basis  Reporting 

170  -  Request  Basis  Updating 

Y:  Character 

1:  Seguential  number  (optional) 


% 


Appendix  A.     DEFINITION  OF  TERMS 

The  following  are  definitions  of  some  of  commonly  used  terms  in 
the  computer  processing  field: 

(RESERVED  FOR  FUTURE  USE) 


Appendix  B.      SYSTEM  COMPONENT  CODES 

The  following  System  Component  Codes  are  used  in  the  Job 
Statement  to  identify  the  component  used  to  submit  a  job. 

T    Operations  Section  local  reader  submitted  jobs  -  testing 
for  ISD  I/O  Services  Section. 

J    Operations  Section  local  reader  submitted  jobs  -  pro- 
duction for  ISD  I/O  Services  Section. 

E    Operations  Section  local  reader  submitted  jobs  -  external 
users,  i.e.  users  not  employed  in  the  ISD  I/O  Section. 

C    TSO  submitted  jobs. 

R     RJE  submitted  jobs. 

K     CICS  submitted  jobs. 


Appendix  C.     AGENCY  AND  GROUP  IDENTIFIERS 

The  following  Agency  and  Group  Identifiers  are  used  in  the  Job 
Statement  to  identify  the  Agency  or  Group  submitting  a  job. 
These  identifiers  are  assigned  by  the  Information  Services 
Division. 

A    Department  of  Administration  -  Systems  Development  Bureau 

B    Department  of  Health  and  Environmental  Sciences 

C    Department  of  Commerce 

D    Department  of  Labor  and  Industry 

E    Department  of  Labor  and  Industry  -  Employment  Security 

Division 
F    Department  of  Fish,  Wildlife  and  Parks 
G    Governor's  Office 
H    Department  of  Highways 
I     Department  of  Institutions 
J    Department  of  Justice 
K    Department  of  Agriculture 
L    Legislature  -  Legislative  Council,   Legislative  Fiscal 

Analyst,  Legislative  Auditor 
M    Department  of  Administration  -  Personnel  Division,  Board 

of  Investments,  Board  of  Housing,  Accounting 
N    Department  of  Natural  Resources  and  Conservation 
P    Superintendent  of  Public  Instruction 
Q    Department  of  Livestock 
R     Department  of  Revenue 

S    Department  of  Social  and  Rehabilitation  Services 
T    Office  of  the  Secretary  of  State 
U    Supreme  Court 

V  Department  of  Administration  -  Public  Employees  Retirement 
Division 

W    Other 

X    Department  of  Administration  -  Operations  Bureau,  Resource 
Management  Unit,  Information  Center  Bureau 

Y  State  Auditor's  Office  -  Central  Payroll  Division 

Z     Department  of  Administration  -  Technical  Services  Bureau 

0  University  System  -  General 

1  Eastern  Montana  College  -  Billings 

2  Montana  State  University  -  Bozeman 

3  Montana  Tech  -  Butte 

4  Western  Montana  College  -  Dillon 

5  Northern  Montana  College  -  Havre 

6  University  of  Montana  -  Missoula 


* 
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1. 

2. 
3. 

ADDRSPC 

CLASS 

MSGCLASS 

4. 
5. 
6. 
7. 

MSGLEVEL 
PRTY 
REGION 
TIME 

Appendix  D.     JOB  CONTROL  LIMITS  AND  DEFAULTS 

JOB  STATEMENT  -  KEYWORD  PARAMETERS 

-  640K 

-  A 

-  9   for  jobs  submitted  via  TSO 

-  A   for  jobs  submitted  by  any  other  method 

-  1,1 

-  1 

-  640K 

-  5  seconds  on  class  H  jobs  only,  no  default 
for  other  jobs 

JOB  CARD  -  OPERATION  CODES 

The  Operation  Code  is  a  two  byte  field.  The  first  byte  controls 
whether  the  operator  is  prompted  in  the  event  the  allotted  CPU 
time  for  a  job  or  job  step  is  exceeded.  The  second  byte 
controls  the  format  of  the  EXCP  BY  UNIT  section  of  the  step 
termination  boxes. 

Valid  Operation  Codes 

Byte-1     Byte-2 

P  The  computer  operator  will  be  prompted  to 

extend  CPU  time  if  the  CPU  time  for  the  job 
or  job  step  is  exceeded.  The  decision  as  to 
whether  the  CPU  time  is  extended,  the  amount 
of  the  extension,  and  the  number  of 
extensions  given  rests  with  the  operator. 
This  option  is  provided  for  special  or 
unforeseen  circumstances;  such  as  instances 
where  processing  time  cannot  be  accurately 
predicted.  It  is  policy  to  cancel  jobs 
which  prompt  for  additional  CPU  time  unless 
special  circumstances  have  been  communicated 
to  the  Central  Computer  Operations  Bureau. 

C  The  job  will  be  cancelled  if  the  CPU  time 

limit  for  the  job  or  job  step  is  exceeded. 
The  operator  will  not  be  prompted. 

S  Requests  a  summarized  EXCP  BY  UNIT  section 
it  the  step  termination  boxes.  The  Unit 
Address  and  EXCP  count  are  displayed  for 
each  DD  statement  used. 

D  Requests  a  detailed  EXCP  BY  UNIT  section  in 
the  step  termination  boxes.  The  DDNAME, 
Maximum  Block  Size  used,  Unit  Address,  and 
EXCP  count  will  be  displayed  for  each  DD 
statement. 


Appendix  D.      JOB  CONTROL  LIMITS  AND  DEFAULTS  (continued) 

JOB  CARD  -  OPERATION  CODES  (continued) 

Valid  Operation  Codes 

Byte-1     Byte-2 

N        Requests  that  no  EXCP  BY  UNIT  section  be 
produced. 


EXEC  STATEMENT  -  KEYWORD  PARAMETER  DEFAULTS 


1 .  ADDRSPC 

2 .  REGION 

3 .  TIME 


-  640K 

-  640K 

-  1  minute 


DP  STATEMENT  -  KEYWORD  PARAMETER  DEFAULTS  AND  ACCEPTABLE  VALUES 

1.  OUTLIM  -  40,000  lines.   The  job  is  not  canceled  but 
warning  messages  are  issued  for  every  10,000  lines  in 
excess  of  the  default. 

2.  UNIT  -  The  following  are  valid  ISD  assigned  group  names: 
a.    TAPE  Default  is  6250  BPI . 

8  00  BPI  tape. 

Direct  access  dataset  retained  only  for  the 

duration  of  the  job. 

Direct  access  dataset  retained  for  eight 

days  from  the  last  date  used  or  for  24  days 

from  the  date  of  creation,  whichever  is 

earlier. 


b. 

TAPELO   : 

c. 

SYSDA 

d. 

TEMPSTOR 

* 


Appendix  E.     MAINFRAME  APPLICATION  SOFTWARE 

The  following  mainframe  software  is  installed  and  supported  to 
the  indicated  level  by  the  Information  Services  Division. 
Software  products  are  grouped  by  support  level . 

FULL  SUPPORT  MAINFRAME  SOFTWARE 

ACF/2-Access  Control  Facility/2 

ADS/O-Application  Development  System/Online 

BMS-GT 

BTP-Batch  Transfer  Program 

CICS/CEMT 

CICS/Command  Level 

VS  COBOL 

CULPRIT 

DCF-Document  Composition  Facility 

Developer  Tool  Kit 

DISOSS  (V3) -Distributed  Office  Support  System 

DYLDOC 

DYLSORT 

DYL2  60 

EasyProcLib 

FORTRAN  VS 

GENX 

IDMS/IDD-Integrated  Data  Dictionary 

IDMS/CV-Integrated  Data  Management  System/Central 

Version 
INTERTEST 
OLQ-Online  Query 
OPTIMIZER  III 
PANLINK 
PANVALET 
PANVALET/TSO 
PM-Personal  Manager 
SAS-Statistical  Analysis  System 

SAS/FSP  Full  Screen  Product 

SAS/ETS  Econometric  Time  Series 
SCRIPT  VS 

SDSF-Spool  Display  and  Search  Facility 
SYNCSORT 
TSO/ISPF-Time    Sharing   Option/Interactive    Structured 

Programming  Facility 
IDMS/UCF-Universal  Communications  Facility 
VPS-VTAM  Printer  Support 
VSAM-Virtual  Sequential  Access  Method 


Appendix  E.      MAINFRAME  APPLICATION  SOFTWARE  (continued) 

LIMITED  SUPPORT  MAINFRAME  SOFTWARE 

BASIC  (VS) 

CICS/Macro  Level 

CICS/SYSD-Debugging  Tool 

FS  CALC  (SAS) 

ICIDU-Diskette  Reader 

UPS-Interactive  Instructional  Presentation  System 

PC/70-Project  Control/70 

TPL/PLL-Table  Producing  Language 

TYPSET  II 

Z CHART 

ZETA  FUNDAMENTAL  SUBROUTINES 

ZETA  FUNCTIONAL  SUBROUTINES 

SUNSET  SUPPORT  MAINFRAME  SOFTWARE 

DAS  (DATA  ADMIN) -Flowcharting  Tool  (no  replacement) 
DITTO/OS 

DYL250  (replaced  by  DYL260) 
FORTRAN  G 

ISAM-Indexed  Sequential  Access  Method 
MARK  IV 

MSUSTAT  (replaced  by  SAS) 

SPSS-Statistical  Package  for  Social  Services 
(to  be  replaced  by  SAS) 

SPECIAL  CASE  MAINFRAME  SOFTWARE 

ALPHA  SEARCH 

ALTER 

INS 

PL1 

SYSM 

TYPE 


Appendix  F.    MICROCOMPUTER  APPLICATION  SOFTWARE 

The  following  microcomputer  software  is  installed  and  supported 
to  the  indicated  level  by  the  Information  Services  Division. 
Software  products  are  grouped  by  support  level. 

FULL  SUPPORT  MICROCOMPUTER  SOFTWARE  PRODUCTS 

CROSSTALK  XVI 

LOTUS  1-2-3 

MS/ DOS  &  PC/ DOS 

PC/SAS  including  STAT  and  GRAPH 

PS/PC-Personal  Services/Personal  Computer 

WordPerfect 

RBase 

Freelance  Plus 

Novell  Netware 

Attachmate  Entry  and  Extra 

IBM  PC  LAN  Program 

PFS:  Professional  File 

IDMS/ARCHITECT 

TAB  -  The  Application  Builder 

ENTERPRISE/GENERATOR/ PC 

LIMITED  SUPPORT  MICROCOMPUTER  SOFTWARE  PRODUCTS 

dBase 

Novell  SNA  products 

SUNSET  SUPPORT  MICROCOMPUTER  SOFTWARE  PRODUCTS 

IBM  3270  Emulation/Entry  Level 
IBM  3270  Emulation/Version  3.0 

SPECIAL  CASE  MICROCOMPUTER  SOFTWARE  PRODUCTS 

OS\2  Extended  Edition 
OS\2  Lan  Server 
Automax 
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I.  Introduction 

The  System  Development  Method  presented  in  this  section  is  a 
guideline  for  system  development.  The  guideline  provides  a 
flexible  framework  within  which  systems  development  projects 
can  be  planned,  designed,  and  developed.  The  method  will  help 
programmer/analysts  plan  and  manage  their  projects. 

II .  Guideline 

This  guideline  consists  of  three  phases.  The  tasks  performed 
in  each  phase,  the  documentation  produced,  and  the  accomplish- 
ments will  vary  from  project  to  project.  This  guideline 
provides  a  list  of  items  from  which  to  pick  and  add  as 
necessary  for  each  project. 

A.  Preliminary  Analysis  -  The  Preliminary  Analysis  should 
result  in  definition  of  the  scope  and  objectives  of  the 
project,  a  statement  of  the  business  and  system  require- 
ments,  and  a  preliminary  plan  for  proceeding  with  the 
project. 

In  addition  to  the  formal  and  informal  documentation 
produced  in  this  phase,  several  less  tangible  accomplish- 
ments are  achieved.  The  project  team  develops  an  under- 
standing of  the  customer's  business  environment, 
problems,  needs,  and  functional  requirements.  The 
customer  gains  an  understanding  of  the  commitment  and 
responsibility  for  developing  and  managing  a  system. 

The  tasks  normally  performed  during  this  phase  include: 

study  the  user's  current  business  environment 
identify  the  user's  business  reguirements 
identify  the  system  reguirements 
develop  a  logical  database  design 
develop  cost  projections 
identify  quantifiable  benefits 
gain  formal  concurrence 
assure  quality 
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Preliminary  Analysis  (continued) 

The  documentation  produced  include  a  memo  or  report 
documenting  the  results  of  the  analysis  including  project 
scope  and  objectives,  business  needs,  system  require- 
ments, cost/benefit,  a  recommendation  of  how  to  proceed 
and  preliminary  plans  for  the  remainder  of  the  project. 
Working  papers  should  also  be  produced  to  document  the 
following: 

-  current  processes  and  systems  used 
interviews 

-  meetings 

-  logical  data  relationships 

-  estimates. 


Software  development  -  During  the  software  development 
phase,  prototyping  is  an  effective  technique  to  use  to 
refine  requirements  and  design  and  develop  a  solution. 
The  prototype  is  an  executable  model  that  demonstrates 
the  functionality  of  the  system  and  provides  a  tangible 
means  of  communicating  with  the  user  to  define  require- 
ments. Prototyping  should  be  done  in  levels,  each  level 
adding  more  depth  of  processing  until  the  full  system  is 
ready  for  acceptance  testing. 

The  tasks  normally  performed  during  the  software  develop- 
ment phase  include: 

support  user  activities 

design  database  and  files 

design  system  flow 

design  online  functions 

design  batch  reporting 

test,  review,  refine 

define  processing  requirements 

estimate  costs  and  benefits 

review  and  monitor  cost  estimates 

define  and  design  conversion  software 

develop  unit  and  system  test  plans 

code  and  test  each  program  module 
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Software  development  (continued) 

The  Level  1  prototype  should  demonstrate  the  functional- 
ity of  the  system  and  provide  a  tangible  means  of  com- 
municating with  the  user  to  define  requirements.  It 
includes  menus,  on-line  screens,  and  navigation  among 
functions.  Some  batch  output  reporting  should  be 
defined. 


The  Level  2  prototype  should  demonstrate  data  access  and 
manipulation  with  on-line  processes  complete  except  for 
integrity,  security,  editing,  and  detailed  processing 
requirements.  The  physical  database  design  should  be 
complete  except  for  performance  tuning. 

The  Level  3  prototype  includes  definition  and  implementa- 
tion of  integrity,  security,  editing,  and  detailed 
processing  requirements  and  completion  of  the  batch 
portions  of  the  software. 

The  deliverables  from  this  phase  include  the  following: 

technical  design  and  support  documentation  includ- 
ing: 

System  Flowcharts 

Database  schema,  subschema,  record,  and  data 

element  definitions 
-    File  Definitions 

Program  Specifications 
system  software  including: 

System  that  is  ready  for  system  testing  by  SDB 

and  the  user 

Program  source  and  object  code 

Job  Control  Language  and  cataloged  procedures 

for  job  execution 

Utility  control  statements 
procedural  documentation 
Operating  instructions 

In  addition,  an  impact  statement  identifying  considera- 
tions for  the  Central  Computer  Operations  Bureau  and  a 
test  plan  should  be  produced  during  this  phase.  Also, 
one-time  software  for  supporting  the  testing  process 
and/or  converting  data  should  be  developed  as  necessary. 
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Software  development  (continued) 

The  user  also  performs  some  important  tasks  during  the 
software  development  phase  including: 

-  Plan  system  test 

-  Draft  user's  manual 

-  Plan  implementation 
Prepare  disaster  recover  plan 
Plan  security 

-  Plan  training 

The  project  team  performs  tasks  which  assure  that  the 
work  completed  during  this  phase  is  correct  and  meets 
standards  and  specifications.  This  is  accomplished  by 
team  member  walkthroughs  and  reviews. 

System  Test  and  Installation  -  During  this  phase  both  the 
development  team  and  the  user  should  test  the  system  to 
insure  that  the  system  meets  the  user's  functional 
business  specifications  before  and  after  installation. 

The  tasks  normally  performed  include: 


-  perform  development  team  system  test 
conduct  user  system  testing 
install  software 

support  automated  conversion  of  data 

review,   update,   and  finalize  technical  support 

documentation 

-  transfer  system  responsibility  to  customer 

The  deliverables  of  this  phase  are  the  technical  design, 
support  documentation,  and  production  software. 

The  results  of  this  phase  are  that  the  project  team  and 
the  customer  find  the  majority  of  the  errors  and 
discrepancies  and  make  the  necessary  changes.  The 
customer  also  develops  expertise  throughout  the  testing 
process  and  is  better  prepared  to  assume  responsibility 
for  the  management  of  the  production  system. 
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I.  Policy 

The  State  Records  Committee  is  composed  of  representatives  from 
the  Department  of  Administration,  Office  of  the  Legislative 
Auditor,  Office  of  the  Attorney  General,  the  Montana  Historical 
Society  and  the  Secretary  of  State. 

A.  The  Committee  will: 

1.  establish  authoritative  standards,   procedures  and 
guidelines  for  public  records  retention. 

2.  promote  sound  records  management  practices  through- 
out State  government. 

B.  This  Committee  shall  meet  at  least  quarterly  to  approve  or 
disapprove: 

1.  the  recommendations  on  retention  schedules  of  all 
public  records. 

2.  agency  requests  to  dispose  of  such  public  records. 

II.  Authorization 

The  State  Records  Committee  is  authorized  by  law,  Sections 
2-15-1013  and  2-6-204,  M.C.A. 

III .  Definitions 

There  are  numerous  definitions  needed  in  the  records  management 
field.  The  most  frequently  used  terms  are  defined  in  alphabetic 
order  in  Appendix  A  of  Public  Records  Management  1-12502. 
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I.  Policy 

A.  Ownership  of  Public  Records  -  All  public  records  are  and 
shall  remain  the  property  of  the  State.  They  shall  be 
delivered  by  outgoing  officials  and  employees  to  their 
successors  and  shall  be  preserved,  stored,  transferred, 
destroyed,  or  disposed  of  and  otherwise  managed  only  in 
accordance  with  the  provisions  of  this  part. 

B.  Public  Records  Management  -  In  order  to  ensure  the  adequate 
protection  and  preservation  of  the  State's  public  records 
the  Department  of  Administration  will  be  responsible  for: 

1.  creating  an  effective  records  management  program  for 
Executive  branch  agencies. 

2 .  providing  records  management  services  to  Executive 
branch  agencies. 

3 .  providing  records  management  advice  and  assistance  to 
the  Legislative  and  Judicial  branches  when  requested. 

4.  providing  records  management  services,  similar  to 
those  available  to  the  Executive  branch,  to  the 
Legislative  and  Judicial  branches  when  requested. 

II .  Authorization 

The  Department  of  Administration  services  are  authorized  by  the 
"Public  Records  Management  Act",  Sections  2-6-201  through  2-6- 
213,  and  2-15-1013,  M.C.A. 

III .  Definitions 

There  are  numerous  definitions  needed  in  the  records  management 
field.  The  most  frequently  used  terms  are  defined  in  alphabetic 
order  in  Appendix  A. 
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I .    Agency  Administration  of  the  Records  Management  Function 

A.  Each  Executive  branch  agency  of  State  government  will 
coordinate  all  aspects  of  the  agency  records  management 
function  and  shall: 

1.  manage  the  inventorying  of  all  public  records  within 
the  agency  for  disposition,  scheduling,  and  transfer 
action  in  accordance  with  procedures  prescribed  by 
the  Department  of  Administration  and  the  State  Records 
Committee. 

2.  analyze  public  records  inventory  data  and  compare 
divisional  or  unit  inventories  for  duplication  of 
records. 

3 .  recommend  to  the  Department  of  Administration  and  the 
State  Records  Committee  minimal  retention  periods  for 
each  copy  of  public  records  within  the  agency. 

4.  approve  all  records  disposal  requests  which  are 
submitted  by  the  agency  to  the  State  Records  Commit- 
tee. 


review  established  records  retention  schedules  to 
insure  that  they  are  complete  and  current. 
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Protection  and  Preservation  of  the  Executive  Branch's  Public 
Records 

The   Department   of   Administration   shall   provide   adequate 
protection  and  preservation  of  the  State's  public  records  by: 


A.  establishing  guidelines  for  inventorying,  cataloging, 
retaining,  and  transferring  all  public  records  of  State 
agencies. 

B.  reviewing  and  analyzing  all  State  agency  filing  systems 
and  procedures  and  approve  filing  system  equipment 
requests. 

C.  establishing  and  operating  the  state  records  center,  as 
authorized  by  appropriation,  for  the  purpose  of  storing 
and  servicing  public  records  not  retained  in  office  space. 

D.  gathering  and  disseminating  information  on  all  phases  of 
records  management,  including  current  practices,  methods, 
procedures,  and  devices  for  the  efficient  and  economical 
management  of  records. 

E.  operating  a  central  microfilm  unit  which  will  microfilm, 
on  a  cost  recovery  basis,  all  records  approved  for  filming 
by  the  office  of  origin  and  the  Department  of  Administra- 
tion. 

F.  approving  microfilming  projects  and  microfilm  equipment 
purchases  undertaken  by  all  state  agencies. 

II.   Services  Available  to  the  Legislative  and  Judicial  Branches 

Upon  request,  the  Department  shall  assist  and  advise  in  the 
establishment  of  records  management  procedures  in  the  Legisla- 
tive and  Judicial  branches  of  State  government  and  shall,  as 
required  by  them,  provide  services  similar  to  those  available 
to  the  Executive  branch. 
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I.    Designating   Certain   Public  Records   as   Essential   for  the 
Continuity  and  Preservation  of  Civil  Government 

Each  elected  and  appointed  officer  of  the  Executive  branch  of 
State  government  shall  provide  for  the  continuity  of  civil 
government.   This  will  be  accomplished  by: 

A.  designating  certain  public  records  as  essential  records 
needed  for  an  emergency  or  for  the  reestablishment  of 
normal  operations  after  any  such  emergency. 

B.  forwarding  a  list  of  such  records  to  the  Department  of 
Administration  where  it  will  be  securely  stored  as  a  backup 
copy. 

C.  periodically  reviewing  the  list  to  insure  its  accuracy. 

D.  forwarding  any  changes  or  revisions  to  the  list  to  the 
Department  of  Administration  where  it  will  be  filed  with 
the  original  list. 


II.   Safeguarding  Certain  Public  Records  for  the  Continuity  and 
Preservation  of  Civil  Government 

Each  elected  and  appointed  officer  of  state  government  shall 
insure  that  the  security  of  essential  records  is  accomplished 
by  the  most  economical  means  possible.  This  will  be  achieved 
by  one  or  a  combination  of  the  following: 

A.  vaulting  the  essential  records. 

B.  planned  or  natural  dispersal  of  copies. 

C.  storage  of  the  essential  records  in  the  State  archives. 

D.  any  other  method  approved  by  the  Department  of  Adminis- 
tration. 
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I .  Reproducing  Essential  Records 

Each  elected  and  appointed  officer  of  state  government  may 
choose  to  reproduce  essential  records  for  added  security. 
Reproductions  may  be  made  by  one  or  a  combination  of  the  follow- 
ing: 

A.  photocopying. 

B.  copying  magnetic  tape. 

C.  copying  to  microfilm. 

D.  copying  by  any  other  method  approved  by  the  Department. 

II .  Preserving  the  Reproduced  Records 

The  Department  of  Administration  recommends  that  reproduced 
copies  of  essential  records  be  managed  and  stored  according  to 
the  Protection  of  Public  Records  procedure,  #:  01. 
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I .  Transfer  of  Public  Records  Not  Required  for  the  Current 
Operation  of  the  Office 

All  public  records  not  required  in  the  current  operation  of  the 
office  where  they  are  made  or  kept  shall  be,  in  accordance  with 
approved  records  retention  schedules,  either: 

A.  transferred  to  the  State  Records  Center. 

B.  transferred  to  the  custody  of  the  state  archives  if  such 
records  are  considered  to  have  either: 

1.  permanent  administrative  value. 

2.  historical  value. 

II .  Transfer  of  Public  Records  for  Services  of  the  Executive  Branch 
Which  May  Be  Abolished  or  Discontinued 

All  public  records  for  agencies,  commissions,  committees,  or 
other  activities  of  the  Executive  branch  which  may  be  abolished 
or  discontinued  shall  be,  in  accordance  with  approved  records 
retention  schedules,  either: 

A.  transferred  to  the  State  Records  Center. 

B.  transferred  to  the  custody  of  the  state  archives  if  such 
records  are  considered  to  have  either: 

1.  permanent  administrative  value. 

2.  historical  value. 
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III .  Rights  of  Control  and  Access  to  Transferred  Public  Records 

The  State  Records  Center  is  only  a  custodian  of  agency  records 
stored  there.  Agencies  that  transfer  records  to  the  State 
Records  Center  retain  ownership  of  the  records  and  all  rights 
of  control  and  access  to  them.  Access  to  stored  records  may 
only  be  obtained  by: 

A.  approval  of  the  owner  agency. 

B.  presenting  a  subpoena  for  access  to  the  owner  agency. 

IV.  Agency  Retention  (Non-Transfer)  of  Public  Records 

Agencies  that  do  not  transfer  records  as  provided  in  an  approved 
retention  schedule  shall,  within  3  0  days,  notify  the  Department 
of  Administration  of  this  decision  and  request  a  change  in  the 
schedule. 
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Requests  for  Disposal  of  Public  Records 

Requests  for  the  disposal  of  public  records  shall  be  submitted 
to  the  State  Records  Committee  by  the  agency  that  owns  the 
records. 


II 


State  Records  Committee  Review 


The  State  Records  Committee  shall  approve,  modify,  or  disapprove 
each  agency  request  to  dispose  of  public  records. 

Ill .  Approval  of  Disposal  of  Public  Records 

No  public  records  may  be  disposed  or  destroyed  without  the 
unanimous  approval  of  the  State  Records  Committee. 


Appendix  A.     DEFINITION  OF  TERMS 

The  following  are  definitions  of  some  of  the  more  common  terms 
used  in  the  records  management  field: 

"Access"  means  permission  to  use  and  reproduce  records.  May  be 
limited  or  gualified  (restricted)  by  the  agency  having 
legal  custody  of  the  records. 

"Active  Records"  means  records  or  materials  which  are  maintained 
in  the  office  of  an  agency  for  current  daily  operations  and 
are  referenced  at  least  once  per  file  drawer  per  month. 

"Administrative  Value"  means  the  usefulness  of  records  to  an 
agency  for  carrying  on  its  day-to-day  work  and  future  work. 

"Aperture  Card"  means  a  standard  si?e  tabulating  card  into  which 
a  rectangular  hole  has  been  cut.  A  special  adhesive  is 
then  applied  around  the  cut-out  area  and  is  used  to  hold 
a  microfilm  image  securely  in  place.  The  aperture  card 
may  be  keypunched  to  permit  mechanical  retrieval. 

"Appraisal  of  Records"  means  an  analysis  of  all  records  within 
an  office  to  determine  their  administrative,  fiscal, 
historical,  or  legal  value  to  that  agency's  operation. 

"Archives"  means  a  depository  for  records  and  information  that 
have  permanent  historical  value. 

"Camera,  Planetary"  means  a  camera  in  which  the  film  unit  is 
suspended  over  a  copyboard  and  is  raised  or  lowered  to 
achieve  the  desired  reduction  ratio.  The  documents  remain 
motionless  on  the  copyboard  while  that  are  filmed. 

"Camera,  Rotary"  means  a  camera  in  which  documents  are  trans- 
ported through  the  machine  by  rotating  belts,  while  the 
image  is  reflected  by  several  mirrors  to  the  lens  of  the 
camera. 

"Camera,  Step-and-Repeat"  means  a  camera  in  which  groups  of 
documents  are  exposed  in  multiple  rows  upon  a  sheet  of 
film.  The  camera  automatically  positions  images  on  the 
film. 

"Cartridge"  means  a  plastic  holder  containing  a  roll  of 
microfilm.  The  entire  unit  can  be  plugged  into  a  microfilm 
reader. 


Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"COM"  means  Computer  Output  Microfilm.  The  process  of  trans- 
lating computer  generated  information  directly  into  human 
readable  language  and  recording  it  on  microfilm. 

"Cubic  Foot"  means  that  volume  of  paper  records  which  will  fill 
a  space  one  foot  high  by  one  foot  wide  by  one  foot  long. 
This  is  the  basic  measurement  for  paper  record  volumes. 

"Custody"  means  the  guardianship  of  records,  whether  it  be 
physical  or  legal  control  of  the  records. 

"Density"  means  the  degree  of  contrast  between  the  image  and 
background  area  of  microfilm.  Density  is  expressed  as  a 
numerical  equivalent  and  measured  by  a  densitometer.  (.8 
to  1.35  is  the  accepted  standard  for  density). 

"Diazo  Film"  means  a  relatively  slow  film  composed  of  AZO  dyes 
that,  in  the  presence  of  strong  light  and  ammonia  vapors, 
are  capable  of  creating  a  positive  image.  Diazo  film  has 
a  shorter  life  than  silver  film  but  is  often  used  in 
duplicating  silver  microfilm  because  it  is  less  expensive 
and  is  of  a  more  scratch  resistant  material. 

"Dispersal  (of  Records)"  means  the  distribution  of  copies  of 
records  outside  their  office  of  origin. 

"Document"  means  an  object  upon  which  information  is  written, 
transcribed  or  recorded. 

"Duplicator"  means  a  machine  for  reproducing  copies  of  exposed 
film  through  a  process  of  contact  printing. 

"Filing  System"  means  the  planned  method  of  indexing  and 
arranging  records. 

"Film  Frame"  means  the  area  of  film  exposed  to  light  through  the 
camera  optical  system  for  one  image. 

"Fiscal  Value"  means  the  usefulness  of  records  for  the  admin- 
istration of  an  agency's  financial  obligations. 

"General  Schedules  or  General  Records  Retention  Schedules"  means 
schedules  which  set  forth  retention  periods  for  records 
common  to  many  or  all  offices  in  State  government. 

"Hard  Copy"  means  an  original  document,  a  paper  copy  made  from  - 
microfilm,  or  a  computer  generated  printout. 


Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"Historical  Value"  means  the  usefulness  of  records  for  histori- 
cal research;  records  which  show  an  agency's  origin, 
administrative  development,  and  present  organizational 
structure. 

"Holdings"  means  all  of  the  records  in  the  custody  of  a  given 
agency,  organizational  element,  archives,  or  records 
center. 

"Image"  means  reproduction  of  a  subject  through  optics,  whether 
it  be  looking  at  an  object  through  lenses  or  the  fixing  of 
the  object  on  film. 

"Inactive  Records"  means  records  having  a  very  low  reference 
rate;  usually  these  records  are  no  longer  needed  in  the 
office  and  are  retained  in  a  low  cost  storage  area. 

"Information  Request"  means  reference  service  provided  by  the 
State  Records  Center,  where  specific  information  from 
records  in  storage  is  transmitted  to  the  requestor. 

"Inventory"  means  the  listing  of  all  record  series  files 
maintained  by  an  office  or  department  together  with  the 
collection  of  operational  data  concerning  files,  volumes, 
and  locations. 

"Jacket"  means  a  transparent  card  (3x5,  4x6)  of  acetate, 
separated  into  chambers  for  inserting  short  strips  of 
microfilm. 

"Legal  Unit"  means  the  usefulness  of  records  containing  evi- 
dence of  legally  enforceable  rights  or  obligations  of 
government  or  citizens. 

"Magnetic  Tape"  means  a  tape  or  ribbon  of  any  material  impreg- 
nated or  coated  with  magnetic  oxide  or  other  material  on 
which  information  may  be  placed  in  the  form  of  magnet- 
ically polarized  spots. 

"Microfiche"  means  a  sheet  of  film  on  which  many  micro-images 
of  related  information  have  been  printed  in  columns  or 
rows. 

"Microfilm  or  Microfilming"  means  the  photographic  reproduction 
of  a  document  on  film.  The  document  may  be  reduced  any- 
where from  one-tenth  to  one-fortyeighth  its  original  t>ize, 
with  such  clarity  that  it  can  be  enlarged  back  to  its 
normal  size  without  loss  of  detail. 

"Microforms"  means  various  types  of  microfilm  images  such  as: 
rolls,  jackets,  fiche,  etc. 


• 
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Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"Microstrips"  means  microfilm  images  up  to  12"  long  contained 
in  a  plastic  sleeve. 

"Non-Records"  means  materials  that  have  no  usefulness  or 
importance  for  the  day-to-day  administration  of  agency 
operations.  Such  things  as  telephone  messages,  routing 
slips,  preliminary  drafts  and  other  messages  of  a  non- 
-policy  nature  are  non-records. 

"Public  Records"  means  any  paper,  correspondence,  form,  book, 
photograph,  microform,  magnetic  tape,  computer  storage 
media,  map,  drawing,  or  other  document,  including  all 
copies  thereof,  regardless  of  physical  form  or  charact- 
eristics, that  has  been  made  or  received  by  a  state  agency 
in  connection  with  the  transaction  of  official  business 
and  preserved  for  informational  value  or  as  evidence  of 
a  transaction  and  all  other  records  or  documents  required 
by  law  to  be  filed  with  or  kept  by  an  agency  of  the  state. 

"Public  Records  Management  Act"  means  Sections  2-6-201  through 
2-6-213,  and  2-15-1013,  M.C.A.,  which  are  designed  to 
create  an  effective  records  management  program  for 
executive  branch  agencies  of  the  state  of  Montana  by 
establishing  guidelines  and  procedures  for  the  efficient 
and  economical  control  of  the  creation,  utilization,  main- 
tenance, and  preservation  of  state  records. 

"Reader"  means  a  device  capable  of  enlarging  micro-images  to  a 
size  that  can  be  read  with  the  naked  eye.  The  images  are 
projected  on  a  ground-glass  screen. 

"Reader-Printer"  means  a  device  that  in  addition  to  enlarging 
micro-images  to  a  readable  size  can  also  make  paper  copies 
(readable  size)  of  selected  images. 

"Record  Series"  means  documents,  volumes,  or  folders  that  are 
arranged  under  a  single  filing  system,  or  are  kept  together 
as  a  unit  because  they  relate  to  a  particular  subject, 
resulting  from  the  same  activity,  or  have  a  particular 
form. 

"Records  Center"  means  a  centralized  area  for  housing  and 
servicing  includes  warehouse  space  for  paper  records  and 
the  central  computer  storage  space  for  electronic  records. 

"Records  Disposal"  means  the  final  placement  of  records,  once 
they  have  served  their  purpose.  This  usually  refers  to 
destruction  of  records. 


Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"Records  Disposition"  means  management  planning  and  analysis  to 
determine  when  records  are  no  longer  needed  for  current 
business.  Determinations  include:  destruction,  transfer 
to  a  records  center,  microfilming  before  destruction,  or 
transfer  to  an  archives. 

"Records  Management  Program"  means  a  comprehensive  system  that 
sets  guidelines  and  procedures  for  the  efficient  economical 
control  of  records  and  information  used  and  kept  by 
agencies  of  state  government. 

"Records  Officer"  means  that  person  designated  by  an  agency  to 
oversee  and  coordinate  a  records  management  program  within 
that  agency. 

"Reference  Date"  means  the  freguency,  within  a  given  period  of 
time,  of  use  of  a  specific  file  or  collection  of  items. 

"Retention  Schedule"  means  an  itemized  list  of  records  series 
with  the  corresponding  time  periods  for  which  they  must  be 
kept. 

"Retrieval"  means  recovering  of  information  or  records,  whether 
through  machine  retrieval,  or  by  recalling  records  from 
storage. 

"Roll  Film"  means  finished  microfilm  retained  and  used  in  100 
or  215  foot  length  and  kept  in  rolls. 

"Scheduling"  means  the  actual  determination  and  writing  of 
retention  periods  for  records. 

"Security  Copies"  means  duplicates  of  records,  stored  in 
safekeeping  facility,  to  provide  backup  for  any  records 
lost  or  destroyed. 

"Silver  Film"  means  film  composed  of  silver  halides  which 
release  free  silver  on  exposure  to  light  and  developer. 
Silver  film  is  used  for  original  negatives  and  prints. 

"State  Records  Committee"  means  a  committee  composed  of 
representatives  of  the  Department  of  Administration, 
Legislative  Auditor,  Attorney  General,  and  the  Montana 
Historical  Society,  to  approve  retention  schedules  for 
public  records,  approve  records  disposal,  and  to  generally 
oversee  a  state  wide  records  management  program. 

"Storage  Cartons"  means  cardboard  boxes  provided  by  the  Records 
Management  Section,  specifically  designed  to  hold  records 
kept  in  storage. 


Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"Target"  means  markers  filmed  on  a  microfilm  roll  that  serve  to 
identify  documents  to  be  filmed,  sectionalize  the  film  for 
easier  reference,  certify  the  documents  on  film  as  true 
copies,  or  to  determine  resolution  of  the  microfilm  images. 

"Transmittal  of  Records"  means  removal  of  records  from  office 
space  and  relocating  them  to  warehouse  space  at  the  state 
records  center. 

"Updating"  means  adding  recently  microfilmed  documents  to 
previously  microfilmed  records. 

"Vital  Records"  means  those  records  that  are  essential  for  the 
operation  and  function,  or  reconstruction  of  a  state 
agency.  These  are  the  records  which  require  security 
storage  or  some  means  of  protection. 
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I.    Policy 


State   agencies   shall  maintain  contingency  plans   for  all 
automated  information  processing  systems  and  data  centers. 

A.  Data  centers  include: 

1.  Departmental   processors,   i.e.   network   servers, 
minicomputers  and  mainframes. 

2 .  mainframe  processors  managed  by  the  Department  of  Ad- 
ministration* s  Information  Services  Division. 

3.  microcomputers  installed  within  each  agency. 

B.  A  high  priority  must  be  placed  on  contingency  planning  for 
systems  that  support  essential  or  critical  services.  Plans 
for  these  systems  are  necessary  in  order  to  provide  reason- 
able assurance  of  service  availability. 

C.  A  list  of  prioritized  systems  for  each  data  center  must  be 
maintained  in  order  to  identify  the  essential/critical 
applications  that  must  be  supported  in  the  event  that  the 
data  center's  contingency  plan  is  placed  in  operation. 

D.  The  absence  of  a  contingency  plan  for  either  the  end  user 
or  the  data  center  will  jeopardize  the  ability  to  support 
the  services  provided  by  the  automated  system  in  the  event 
of  a  disaster. 


II .  Background 

Service  continuity  is  a  key  factor  in  the  efficient  performance 
of  agency  functions.  Contingency  plans  provide  reasonable 
assurance  that  services  can  be  continued  in  the  event  of  a 
disruption  to  information  processing  resources.  These  plans  are 
particularly  important  for  those  services  that  are  identified 
as  critical  or  essential  to  the  c^ency. 

III .  Definitions 

There  are  numerous  definitions  relating  to  contingency  planning. 
The  most  freguently  used  terms  are  defined  in  alphabetic  order 
in  Appendix  A. 
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Prioritizing  Information  Systems 

The  Information  Services  Division  working  with  the  Data 
Processing  Advisory  Council  shall  establish  and  maintain  a 
prioritized  list  of  application  categories  for  those  systems 
utilizing  mainframes  managed  by  ISD. 

A.  This  list  will  be  used  by  State  agencies  to  classify 
applications. 

B.  Agencies  must  inform  ISD  of  the  applications  that  are 
classified  in  each  category. 

C.  The  Information  Services  Division  will  use  the  agency  lists 
as  a  basis  for  allocating  resources  in  the  event  of  a 
disaster  which  impacts  central  computing  services. 

The  current  priority  categories  are  available  in  Appendix  B. 
PRIORITIZING  INFORMATION  SYSTEMS. 
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I.  End  User  Contingency  Planning 

End  Users  shall  develop,  document  and  test  plans  to  ensure  that 
agency  services  that  rely  on  automated  systems  can  be  managed 
during  a  period  when  the  supporting  data  center  is  out  of 
service. 

II .  Scope  of  Responsibility 

A.  Develop  contingency  plans  for  all  systems  residing  on: 

1.  Departmental   processors,   i.e.   network   servers, 
minicomputers  and  mainframes. 

2.  mainframe  processors  managed  by  the  Department  of  Ad- 
ministration's Information  Services  Division. 

3.  microcomputers  installed  within  the  agency. 

B.  Ensure  that  all  system  (operations  and  user)  documentation 
for  the  automated  system  is  current  and  that  copies  of  it 
are  included  with  the  contingency  plan  for  the  system. 

C.  Ensure  that  all  data  and  other  required  resources  are 
backed  up  and  stored  off -site. 

D.  Store  current  copies  of  all  contingency  plans  in  a  secure 
off-site  location. 

E.  Identify  the  Priority  Categories  that  best  fit  each  system. 
Use  Appendix  B.  PRIORITIZING  INFORMATION  SYSTEMS  to  assist 
in  this  identification. 

F.  Inform  the  appropriate  data  center  management  of  the 
priority  systems. 

G.  Arrange  for  system  tests,  including  system  portability, 
using  the  data  center's  contingency  plans. 
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III.  Contingency  Plan  Maintenance 

Reliable  contingency  plans  require  periodic  attention  to  ensure 
their  usefulness.   This  maintenance  includes: 

A.  Updating  the  contingency  plan  when  routine  operational 
procedures  change. 

B.  Providing  awareness  training  for  personnel  who  would  be 
expected  to  participate  in  executing  the  contingency  plan 
in  the  event  of  a  data  center  service  outage. 

C.  Periodic  testing  of  alternate  processing  arrangements  to 
verify  their  adequacy. 

D.  Periodic  testing  of  system  portability  in  cooperation  with 
the  host  data  center.  This  tests  both  the  end  user  and 
data  center  contingency  plans. 

E.  Periodic  verification  of  recovery  materials  stored  off- 
site.  This  includes  data,  software,  system  documentation 
and  supplies. 


F.    Assigning  responsibility  for  contingency  plan  maintenance. 
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I.    Introduction 

Contingency  plans  are  to  provide  guidance  for  agency  personnel 
in  the  event  that  the  automated  system  suffers  a  temporary  loss 
of  service  or  an  extended  loss  due  to  a  major  disaster.  This 
guidance  should  enable  the  agency  to  provide  service  continuity 
until  the  automated  system  can  be  restored  to  its  normal 
activity. 

II.   Identifying  Essential/Critical  Applications 


Each  automated  system  should  be  evaluated  to  identify  how 
essential  the  system  is  to  the  agency.  All  systems  need 
contingency  plans  and  those  whose  loss  of  service  would 
seriously  impact  the  agency  should  be  among  the  first  to  be 
covered  by  such  a  plan.  Use  the  information  obtained  from  this 
evaluation  to  prioritize  the  systems. 

As  an  aid  for  identifying  essential  automated  systems  consider: 

A.  How  long  the  system  could  be  unavailable  before  impacting 
agency  services.  Use  specific  time  frames  such  as  1  hour, 
1  day,  1  week,  1  month,  3  months. 

B.  The  impact  of  a  data  entry  backlog.  What  would  happen  if 
the  outage  occurred  during  a  period  of  time  when  large 
amounts  of  data  is  received  for  processing. 

C.  The  number  of  agency  personnel  who  would  be  unable  to 
perform  their  tasks  during  the  service  outage. 

D.  The  need  to  respond  to  inquiries  from  other  State  agencies, 
Federal  agencies,  businesses  or  the  public. 

E.  The  impact  on  agency  revenue  collections  or  payments. 

F.  The  impact  on  meeting  any  statutory  requirements  for  the 
agency. 
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III.  End  User  Contingency  Plan  Outline 

A.  Identify  the  system  or  application  by  name  with  a  brief 
description  of  its  function. 

B.  Specify  where  the  application  software  resides,  i.e.  what 
computer  hardware  or  data  center  is  involved. 

C.  Identify  agency  personnel  who  should  be  contacted  in  the 
event  of  a  service  disruption. 

D.  Identify  the  acceptable  outage  period  before  the  contingen- 
cy plan  is  to  be  placed  in  action. 

E.  Describe  in  detail  the  alternate  manual  (clerical) 
procedures  to  be  followed  during  the  outage  period. 

F.  Describe  in  detail  any  system  (operations  and  user) 
procedures  to  be  used  if  the  system  can  be  moved  to 
alternate  hardware  or  an  alternate  data  center. 

G.  Describe  in  detail  the  steps  that  will  need  to  be  taken  in 
order  to  recover  the  system  to  its  normal  state  once 
service  is  restored. 
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I.  Data  Center  Contingency  Planning 

Data  center  managers  shall  develop  and  document  contingency 
plans  to  ensure  that  essential  or  critical  information  process- 
ing services  provided  at  the  site  can  be  supported  in  the  event 
of  a  service  disruption. 

II .  Scope  of  Responsibility 
The  data  center  shall: 

A.  Develop  and  distribute  system  portability  guidelines  to  all 
data  center  users. 

B.  Maintain  a  list  of  all  essential/critical  systems  served 
by  the  facility  and  prioritize  them  according  to  the  list 
of  critical  application  categories  and  the  agency's 
priority.  Refer  to  Appendix  B.  PRIORITIZING  INFORMATION 
SYSTEMS  for  the  list  of  critical  application  categories. 

C.  Develop  contingency  plans  that  address  alternative 
procedures  for  maintaining  information  processing  services 
for  at  least  the  highest  priority  systems  in  the  event  that 
the  data  center  is  out  of  service.   Data  centers  include: 

1.  Departmental   processors,   i.e.   network   servers, 
minicomputers  and  mainframes. 

2.  mainframe  processors  managed  by  the  Department  of  Ad- 
ministration's Information  Services  Division. 

3.  microcomputers  installed  within  the  agency. 

D.  Store  current  copies  of  all  contingency  plans  and  the  list 
of  critical  applications  in  a  secure  off-site  location. 
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III.  Contingency  Plan  Maintenance 

Reliable  contingency  plans  require  periodic  attention  to  ensure 
their  usefulness.   This  maintenance  includes: 

A.  Assigning  responsibility  for  contingency  plan  maintenance. 

B.  Updating  the  contingency  plan  when  routine  operational 
procedures  change. 

C.  Updating  the  contingency  plan  when  hardware  changes  are 
made. 

D.  Periodic  testing  of  alternate  processing  arrangements  to 
verify  their  adequacy. 

E.  Providing  awareness  training  for  personnel  who  would  be 
expected  to  participate  in  executing  the  contingency  plan 
in  the  event  of  a  data  center  service  outage. 

F.  Periodic  verification  of  recovery  materials  stored  off- 
site.  This  includes  data,  software,  system  documentation 
and  supplies. 
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I .  Introduction 

Contingency  plans  are  to  provide  guidance  for  data  center 
personnel  in  the  event  that  the  data  center  suffers  a  temporary 
loss  of  service  or  an  extended  loss  due  to  a  major  disaster. 
This  guidance  should  enable  the  data  center  to  provide  service 
continuity  for  the  essential/critical  systems  until  the  facility 
can  be  restored  to  its  normal  level  of  service. 

II .  Objectives  of  the  Data  Center  Contingency  Plan 

The  data  center's  contingency  plan  for  the  computer  facility 
should  include: 

A.  Identification  of  a  viable  backup  computer  facility  for  the 
restoration  of  essential  State  agency  services. 

B.  A  description  of  the  resources  available  at  the  backup 
computer  facility. 

C.  Emergency  response  procedures  to  support  the  continuity  of 
essential  State  agency  services. 

D.  Specifications  and  general  procedures  for  establishing  and 
testing  portable  systems. 

E.  Examples  of  proper  contingency  documentation  for  automated 
systems. 

F.  Provisions  to  make  data  center  personnel  and  processing 
resources  available  to  assist  agency  personnel  with  sched- 
uled tests  of  critical  automated  systems  including  the 
portability  of  those  systems. 

G.  Provisions  for  operational  support  at  the  backup  computer 
facility  for  critical  information  systems  in  the  event  the 
data  center  is  unavailable. 
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III.  Identifying  Potential  Causes  for  Loss  of  Service 

The  following  items  should  be  considered  when  developing  a 
Contingency  Plan  for  data  centers.  It  is  advisable  to  consider 
each  topic  and  prepare  a  contingency  plan  for  each  computer 
hardware  site. 

A.  EMERGENCY  SITUATIONS 

1.  High  Temperature  Condition 

2 .  Power  Outage 

3 .  Fire  and/or  Smoke 

4.  Uncontrolled  Water  at  the  Computer  Site 

5.  Earthquake 

6.  Tornado  or  Extremely  High  Winds 

7 .  Bomb  Threat 

8.  Riot  or  Civil  Disturbance 

9 .  Other 

B.  COMPONENT  FAILURE 


1.  Microcomputers 

2.  Departmental   Processors,   i.e.   Network   Servers, 
Minicomputers  or  Mainframe  Computer  Systems 

3.  Communications  Controllers 

4 .  Local  Area  Network 

5.  State  Telecommunications  Network 

6.  Peripheral  Devices  (keyboards,  monitors,  printers, 
backup  tape  units,  etc.) 

7.  Environmental  Support  Equipment  (heating,  cooling,  air 
conditioning,  etc.) 
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IV.   Data  Center  Contingency  Plan  Outline 

The  data  center  contingency  plan  should  separately  address  each 
of  the  potential  causes  for  loss  of  service  listed  in  Section 
III  of  this  guideline.  The  following  points  should  be  con- 
sidered when  developing  and  maintaining  the  plan. 

A.  Describe  the  emergency  response  procedures  to  be  followed 
in  each  case.   Identify: 

1.  Specific  actions  that  need  to  be  taken  immediately. 

2.  Emergency  services,  i.e.  fire  or  police,  that  should 
be  contacted. 

3.  Agency  personnel  who  should  be  contacted. 

B.  Describe  how  to  prepare  a  damage  assessment  report  detail- 
ing the  sequence  of  events  leading  up  to  the  loss  of 
service. 

C.  Estimate  the  length  of  outage  for  data  center  services  and, 
based  on  this  estimate,  identify  the  appropriate  action  to 
be  taken.   Actions  that  may  be  considered  are: 

1.  No  action  except  to  wait  for  service  to  be  restored. 

2.  Move  the  operation  to  an  alternate  site,  i.e.: 

a.  a  local  data  center. 

b.  an  established  cold  site. 

c.  an  established  hot  site. 

D.  If  alternate  site  processing  is  selected  be  sure  that 
instructions  identifying  the  following  are  available. 

1.  Management  and  operational  responsibilities. 

a.  Management  personnel  and  calling  list. 

b.  Operations  personnel  and  calling  list. 

2.  Transition  and  start  up  procedures 

3.  Data  center  application/system  priorities. 

4.  Procedures   for   obtaining   data   center   supplies, 
necessary  files  and  other  processing  needs. 

5.  Data  file  restoration  procedures. 

6.  Computer  application  support  personnel. 

7.  Procedures  for  establishing  on-line  access. 

8.  Backup  procedures  including  off-site  storage. 

9.  Report  distribution. 
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IV.   Data  Center  Contingency  Plan  Outline  (continued) 

E.  Describe  the  site/service  restoration  and  the  service 
vendors  that  may  be  needed  based  upon  the  Damage  Assessment 
Report.   Include: 


Recovery  administrative  team  identification. 
Disaster  declaration  and  required  notifications 
Restoration  procedures  including  vendors. 

a.  Facility  repair/ replacement . 

b.  Equipment  repair/replacement. 
Media  expenses. 

Other  expenses. 


Describe  what  will  need  to  be  done  to  return  the  data 
center  to  normal  processing.   Include  identifying: 

1.  The  recovery  operations  team. 

2.  Service  recovery  procedures  for  all  affected  services. 

2.  Data  file  restoration  procedures.   Include  any  file 
updating  required  to  make  the  data  current. 

3.  Computer  application  support. 

4.  Procedure  for  restoring  on-line  access. 

5.  Procedure  for  re-establishing  report  distribution. 

Other  considerations  include: 


6. 

7. 

8. 

9. 
10 
11. 
12. 
13. 


Damage  Assessment  Forms. 

Calling  Lists  -  Employees  and  Users. 

Vendor/Resource  Contracts. 

Disaster  Recovery  Logs. 

Equipment  inventories  for  all  affected  sites.  Include 

environmental  support  equipment  as  well  as  computers 

and  peripherals. 

Floor  plans  for  all  affected  sites. 

Power  requirements. 

Environmental  requirements. 

Software  licenses. 

Production  processing  schedules. 

Off -site  supply  inventories. 

Contingency  plan  contracts. 

Change  notices. 
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Appendix  A.     DEFINITION  OF  TERMS 

The  following  are  definitions  of  some  of  the  more  common  terms 
used  in  contingency  planning: 

"Affects"  means  indirectly  or  intangibly  causes  an  effect  in 
time  of  crisis. 

"Application  Risk  Assessment"  means  the  formal  process  of 
evaluating  the  vulnerability  of  information  technology  resour- 
ces, estimating  the  costs  of  potential  losses,  identifying 
alternative  means  of  removing  or  limiting  the  risks. 

"Contingency  Plan"  means  a  collection  of  plans,  procedures, 
arrangements  and  information  which  are  completed,  compiled  and 
held  in  readiness  for  use  in  the  event  of  disruption  of  normal 
activities. 

"Critical  Application"  means  an  information  processing  applica- 
tion supporting  an  essential  function  which  fits  at  least  one 
of  the  following  criteria: 

1.  Processing  of  the  application  is  reguired  for  con- 
tinuity of  essential  functions  in  the  event  of  a 
disaster. 

2.  If  the  application  were  handled  manually,  the 
resulting  backlog  of  processing  could  not  be  recovered 
in  a  reasonable  time  after  restoration,  given  the 
information  resource  capacity  available. 

"Crucial"  means  important  or  essential  in  time  of  crisis. 

"Data  and  Information  Technology  Resources"  means  data  process- 
ing mainframe,  microcomputer  hardware,  peripherals,  software, 
special  forms,  personnel,  facility  resources,  maintenance, 
training,  electronically  stored  data,  or  other  related  resour- 
ces. 

"Data  Center"  means  any  computer  device  including: 

1.  Departmental  processors,  i.e.  network  servers, 
minicomputers  and  mainframes. 

2.  mainframe  processors  managed  by  the  Department  of  Ad- 
ministration's Information  Services  Division. 

3.  microcomputers  installed  within  the  agency. 

"Disaster  Recovery  Plans"  means  plans  established  to  respond  to 
disruptions  resulting  in  prolonged  unavailability  of  informa- 
tion assets  such  that  it  interferes  with  the  State's  ability  to 
deliver  essential  services. 
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Appendix  A.     DEFINITION  OF  TERMS  (continued) 

"Emergency  Response  Procedures"  means  procedures  established 
for  immediate  response  to  any  actual  or  impending  situation  that 
can  cause  injury,  loss  of  life,  destruction  of  property  or 
interference  with  normal  activity  such  that  information  assets 
will  be  rendered  partially  or  totally  inoperable  or  unavail- 
able. 

"Essential  Function"  means  any  function  supporting  a  major  State 
of  Montana  cash  flow  mechanism  or  an  essential  service  required 
to  maintain  operation  of  the  State  government  during  a  sustained 
loss  of  information  resources  of  as  much  as  three  months 
duration. 

"Information  Processing  Center"  means  any  computer  that  is  used 
to  store  data,  produce  reports,  support  work  stations,  and/or 
communicate  with  a  host  computer  or  other  computers. 

"Portable  System"  means  that  the  application  software  is 
designed  in  such  a  manner  that  it  can  function  using  the 
resources  which  are  available  at  the  designated  backup  computer 
facility. 
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Appendix  B.      PRIORITIZING  INFORMATION  SYSTEMS 

The  following  priority  categories  have  been  established  to 
assist  in  identifying  information  systems  that  are  critical  to 
maintaining  State  agency  services  in  the  event  of  a  disruption 
in  computer  services.  Agencies  are  responsible  for  informing 
their  computer  service  Data  Center  of  the  priority  category  that 
best  applies  to  each  of  their  application  sets. 

Applications  are  to  be  classified  in  one  of  the  following 
priority  categories  which  are  listed  in  order  from  the  most 
critical  to  the  least: 

PRIORITY   PRIORITY  CATEGORY 

1.  Crucial  to  Public  Safety  and  Health 

2.  Crucial  to  Payment  of  Vital  Obligations 

3 .  Crucial  to  Generation  of  Vital  Revenue 

4 .  Crucial  to  Operation  of  State  Government 

5.  Affects  Public  Safety  and  Health 

6.  Crucial  to  Satisfaction  of  State  Legislative  Mandates 

7.  Crucial  to  Non-critical  Public  Services 

8.  Crucial   to   Satisfaction   of   Federal   Legislative 
Mandates 

9.  Affects  Payment  of  Obligations 

10.  Affects  Operation  of  State  Government 

11.  Affects  Generation  of  Revenues 

12.  Affects  Satisfaction  of  State  Legislative  Mandates 

13.  Affects  Satisfaction  of  Federal  Legislative  Mandates 

14.  Affects  Non-Critical  Public  Services 
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I.  Policy 

In  order  to  ensure  the  adequate  protection  of  the  State's  data 
and  information  technology  resources: 

A.  the  Department  of  Administration  shall  provide  centralized 
management  and  coordination  of  State  policies  for  security 
of  data  and  information  technology  resources. 

B.  each  department  head  shall  assure  an  adequate  level  of 
security  for  all  data  and  information  technology  resources 
within  their  department. 

II .  Authorization 

The  Department  of  Administration  and  the  other  departments  of 
State  government  have  been  directed  by  the  Legislature  to 
provide  an  adequate  level  of  security  for  data  and  information 
technology  resources  within  their  respective  departments 
(Sections  2-17-503  and  2-15-114,  MCA). 

III.  Definitions 


"Data  and  Information  Technology  Resources"  means  data 
processing  mainframe,  microcomputer  hardware,  peripherals, 
software,  special  forms,  personnel  facility  resources, 
maintenance,  training,  electronically  stored  data,  or  other 
related  resources. 

"Production  Data  Sets"  are  computer  files  that  contain 
information  that  directly  or  indirectly  affects  the  ongoing 
operation  of  the  agency.  This  includes  both  data 
maintained  by  application  systems  and  administrative 
support  systems  (word  processing  files,  spreadsheets, 
automated  calendars,  etc.)  on  ISD's  mainframes  and/or 
departmental  microcomputers  and  other  processors.  Although 
the  loss  of  computer  files  created  to  test,  demonstrate, 
or  evaluate  systems  may  impact  agency  operations  they  are 
not  considered  production  data  sets  for  the  purposes  of 
this  policy. 
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I.  Controlling  Access  to  Data  and  Information  Technology  Resources 

In  order  to  ensure  the  adequate  protection  of  the  State's  data 
and  information  technology  resources  through  active  management 
of  access  control  procedures  each  State  agency  will: 

A.  be  responsible  for  controlling  access  to  data  and 
information  technology  resources  owned  or  managed  by  the 
agency. 

B.  designate  at  least  two  agency  employees  as  the  agency's 
Security  Officer  and  alternate  agency  Security  Officer 
whose  responsibilities  will  be  to  ensure  that  only 
authorized  users  will  have  access  to  the  agency's  data  and 
information  technology  resources. 

II .  Mainframe  Access  Control 

Mainframe  access  control  to  data  and  information  technology 
resources  will  be  performed  by  agency  Security  Officers  through 
the  use  of  a  software  tool  called  Access  Control  Facility-2 
(ACF2) .   Control  will  be  exercised  by: 

A.  identifying  to  the  Department  of  Administration's  Central 
Security  Officer  those  users  authorized  to  access  agency 
data  and  information  stored  on  the  Department  of 
Administration's  mainframe  computer. 

B.  writing  ACF2  rules  which  will  control  the  level  of  access 
to  the  agency's  data  and  information  stored  on  the 
Department  of  Administration's  mainframe  computer. 
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I.  Identification  of  Agency  Security  Officers 

A.  The  Department  of  Administration's  Central  Security  Officer 
will  acknowledge  an  agency's  Security  Officer  and  alternate 
Security  Officer  upon  receipt  of  a  letter  or  letters 
identifying  these  individuals. 

B.  Letters  must  be  on  agency  letterhead  stationary  and  signed 
by  the  appropriate  agency  management. 

II.  ACF2  Training 

The  Department  of  Administration's  Central  Security  Officer  will 
make  ACF2  training  available  to  each  designated  agency  Security 
Officer  and  alternate.  The  effectiveness  of  agency  Security 
Officers  can  be  substantially  increased  through  specialized 
training  in  the  use  of  ACF2  security  software. 

A.  The  Department  of  Administration  recommends  that  all  agency 
Security  Officers  receive  this  training  before  attempting 
to  write  the  ACF2  rules  for  controlling  user  access  to 
agency  data  and  information. 

B.  Individual  or  group  instruction  is  available  to  all  agency 
Security  Officers  and  provided  on  reguest  from  the 
Department  of  Administration's  Central  Security  Officer. 
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Controlling  Access  to  Agency  Data  and  Information 

Agency  Security  Officers  are  responsible  for  maintaining  control 
over  user  access  to  production  datasets  of  agency  data  and 
information.   Agency  Security  Officers  will: 

A.  Write  the  necessary  ACF2  rules  to  authorize  user  access  to 
agency  data  and  information.  These  rules  will  specify  the 
level  of  access  authority  for  each  user. 

B.  Maintain  a  list  of  authorized  users  and  the  level  of 
privileges  assigned  to  each. 

D.  Regularly  review  ACF2  reports  to  detect  any  security  viol- 
ations or  unauthorized  access  attempts. 

E.  Research  suspected  access  attempts  and  report  any  confirmed 
security  violations  to  the  Department  of  Administration's 
Central  Security  Officer. 

F.  Promptly  notify  the  Department  of  Administration's  Central 
Security  Officer  of  the  termination  of  any  employees  who 
are  ACF2  authorized  users. 
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II .   Controlling  Unauthorized  Access  to  Production  Datasets 

A.  The  Department  of  Administration's  Central  Security  Officer 
will  prohibit  unauthorized  access  to  production  datasets 
unless  the  agency  Security  Officer  specifies  rules  to  the 
contrary. 

B.  In  order  to  control  unauthorized  use  of  mainframe  log-on 
identification  numbers,  the  Department  of  Administration's 
Central  Security  Officer  will: 

1.  maintain  a  list  of  authorized  dataset  prefixes. 

2.  periodically  review  log-on  identification  number 
activity  and  suspend  those  log-on  identification 
numbers  not  used  within  the  past  90  days. 

3.  suspend  log-on  identification  numbers  of  terminated 
employees. 

4.  restrict  the  reassignment  of  log-on  identification 
numbers. 
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Controlling  Access  to  Databases  and  Sensitive  Information 
The  Department  of  Administration  recommends  that: 

A.  agencies  evaluate  the  access  risks  and  security  require- 
ments for  data  and  systems  owned  or  managed  by  the  agency. 

B.  the  security  features  of  the  data  base  management  system 
should  be  employed  according  to  the  system's  security 
requirements  if  the  system  is  a  database  controlled  by 

IDMS. 

C.  all  the  security  features  of  the  teleprocessing  monitor 
should  be  used  to  restrict  access  only  to  authorized  in- 
dividuals for  all  systems  that  provide  on-line  access. 

D.  custom  security  techniques  should  be  developed  to 
supplement  additional  controls  if  information  is  financial 
or  sensitive  in  nature. 

E.  custom  security  systems  should  encrypt  user  sign-ons  if 
the  disclosure  risk  is  high. 
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I.    Policy 


Software  residing  on  mainframes  operated  or  managed  by  the 
Department  of  Administration's  Information  Services  Division 
will  be  controlled  to  minimize  the  possibility  of  unauthorized 
access,  processing  errors,  manipulation,  misuse,  and  inten- 
tional or  accidental  loss  of  data. 


II 


Definitions 


There  are  numerous  terms  relating  to  mainframe  software.  The 
most  frequently  used  terms  are  defined  in  alphabetic  order  in 
Appendix  A. 


Appendix  A.     DEFINITION  OF  TERMS 

The  following  are  definitions  of  some  commonly  used  terms  in  the 
computer  processing  field: 
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